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RESEARCH  AND 
ENGINE  E  RING 


Dear  Friend  of  Ada: 

Thank  you  for  your  interest  in  Ada. 

Your  name  has  been  added  to  the  Ada  mailing  list,  and 
occasionally  you  will  receive  information  from  the  Ada  Joint 
Program  Office  concerning  the  status  of  the  Ada  program. 

Under  the  Freedom  of  Information  Act,  the  Ada  Joint  Program 
Office  (AJP9)  mailing  list  is  being  made  available  on  the 
USC-^EC13  computer.  If  you  object  to  inclusion  of  your  name  on 
this  public  list,  please  inform  the  AJPO  in  writing.  To  help 
keep  the  list  up-to-date,  please  notify  the  WPQ  of  address 
changes. 


Sincerely, 


Larry  E.  Druffel,  Lt.'Ool.,  USAF 
Director,  Ada  Joint  Program.  Office 


This  "Tinman"  document  represents  the  requirements  of  the  Department  of 
Defense  for  High  Order  Computer  Programming  Languages.  This  is  the  position  of 
the  representatives  of  the  Military  Departments,  as  presently  formulated;  however, 
it  should  be  regarded  as  a  living  document  to  be  modified  as  requirements  become 
more  specific,  as  technical  capabilities  are  better  appreciated,  or  as  expansion  of 
the  explanations  becomes  indicated.  Comments  are,  therefore,  actively  solicited 
on  all  levels  and  may  be  addressed  to  the  Chairman  of  the  High  Order  Language 
Working  Group: 


Lt.  Col.  William  A.  Whitaker 
Defense  Advanced  Research  Projects  Agency 
1400  Wilson  Boulvard 
Arlington, Virginia  22209 
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I.  Introduction 


Like  most  large  computer  users,  the  United  States  Department  of  Defense  has 
been  plagued  with  a  proliferation  of  high  order  languages  and  incompatible  systems 
serving  the  "same"  language.  The  DoD’s  problems  are,  in  principal,  no  different  from 
the  rest  of  the  computer  user  community;  they  are  simply  larger  as  is  the  use  of 
computers.  Further,  DoD  systems  are  often  individually  very  la;  ge  and  very  long 
lived.  Because  of  the  intimate  integration  of  the  computer  resources  with  the  rest  of 
a  large  defense  system,  it  has  not  been  possible  to  change  computer  subsystems  with 
frequency  which  might  characterize  a  commercial  operation.  As  a  result, 
maintenance  of  the  computer  system  is  both  long  term  and  dynamic,  and  maintenance 
in  many  cases  involves  modification  of  the  system  to  respond  to  new  threats. 
Defense  systems  are  often  composed  of  interacting  but  independently  developed 
subsystems,  sometimes  brought  into  existence  over  a  period  of  years,  all  of  which 
must  be  served  by  a  common  but  evolving  hardware  base.  In  such  an  environment, 
the  Department  of  Defense  finds  itself  spending  an  increasingly  larger  fraction  of  its 
systems  resources  on  software.  High  order  language  commonality  and  the  resulting 
flexibility  would  provide  a  powerful  tool  for  reducing  the  high  cost  of  software  in  the 
DoD. 


With  each  of  the  Military  Departments  studying  this  problem  and  making 
proposals  for  common  languages,  it  was  clear  that  the  greatest  benefit  could  be 
reaped  by  providing  languages  common  across  the  Department  of  Defense.  In 
January  1975,  a  DoD  High  Order  Lanugage  Working  Group  (HOLWG)  was  chartered 
by  DDR&E  with  representatives  from  the  Military  Departments  to  investigate  the 
requirements  and  specifications  for  programming  language  commonality,  to  compare 
these  with  existing  approaches,  and  to  recommend  adoption  or  implementation  of  the 
necessary  common  language  or  languages.  Until  the  matter  is  resolved,  the  DoD  will 
not  support  any  further  implementation  of  new  high  order  languages  in  R&D 
programs. 

— 'The  first  task  of  the  HOL  Working  Group  was  to  formulate  a  set  of 
requirements  consistent  with  the  levies  of  the  Military  Departments.  This  effort 
proceeded  as  follows;  ; 

While  there  is  no  intent  to  replace  the  already  standard  COBOL  and  FORTRAN 
in  their  field  of  application,  initially  there  was  no  reason  to  unnecessarily  restrict  the 
requirements  to  only  those  areas  such  as  real-time  applications  or  weapons  systems 
where  the  major  problems  are,  although  this  area  must  receive  emphasis. 
Therefore,  requirements  were  solicited  from  as  broad  a  base  as  possible,  to  be 
prioritized  later  as  required.  Further,  inquiries  were  not  restricted  to  those 
programs  presently  using  high  order  languages,  rather,  a  major  thrust  of  the  effort  is 
to  provide  HOL’s  to  meet  the  requirements  of  those  who  are  now  constrained  to  use 
an  assembly  language  for  lack  of  a  suitable  HOL.  _  . 

■  V.v*f  p>  J  . 
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A  major  problem  was  to  formulate  the  inquiry  in  such  a  way  that  meaningful 
requirements  would  result.  On  the  one  hand,  one  wishes  to  avoid  broad  generalities 
such  as  the  obvious  goals  of  efficiency,  ease  of  coding,  readability,  etc.,  which,  while 
are  very  real  goals,  are  insufficiently  quantified  to  provide  any  detailed  guidance.  On 
the  other  hand,  to  over  specify  the  requirements  at  the  level  of  individual  language 
features  would  merely  formalize  past  idiosyncrasies  and  magnify  distinctions  which 
do  not  represent  fundamental  differences.  It  has  proved  to  be  impossible  to  define 
rigorously  the  exact  level  requirement  desired;  and,  therefore,  a  ’’strawman''  of 
preliminary  requirements  was  established  to  define  this  level  by  illustration.  The 
"strawman”  was  not  intended  to  be  complete  or  consistent,  rather  it  was  deliberately 
provocative  in  order  to  elicit  the  widest  possible  comment.  It  was  forwarded  to  the 
Military  Departments  and,  by  them,  to  their  various  operating  organizations.  In 
addition,  it  was  distributed  to  other  government  agencies,  to  the  academic  community, 
and  to  industry,  through  industry  organizations  and  military  contractors,  and  by  direct 
inquiry.  A  number  of  individuals  outside  the  U.S.  were  also  solicited  for  comments. 
Hundreds  of  individuals  and  organizations  have  had  an  opportunity  to  examine  this 
document  and  provide  inputs,  the  bulk  of  such  inputs  were  positive  and  useful. 
Negative  comments  were  almost  universally  based  on  a  misunderstanding  of  the 
status  of  the  document.  Believing  this  to  purport  to  be  a  complete  and  consistent  set 
of  requirements  some  correctly  pointed  out  that  it  was  no  such  thing. 

^The  results  of  four  months  of  such  input  were  put  together  in  a  more  concrete 
form,  one  which  could  then  pretend  to  represent  a  fairly  complete  set  of 
requirements,  although  still  a  tentative  set.  This  document  was  called 
the"woodenmanj  "  and  it  too  was  distributed  widely.  It  provided  a  more  rigorous 
fr  amework  for  specific  comment.  On  the  basis  of  all  inputs  and  the  official  responses 
from  each  of  the  Mi'itary  Departments,  a  more  complete  set  of  requirements  has 
evolved  and  is  presented  here  as  a  "tinman."  This  document  represents  a  set  of 
requirements  for  high  order  computer  programming  language  consistent  with  the 
input  from  the  Military  Services. 
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II.  Definition 

A  high  order  language  (HOL)  is  one  which  provides  compression  of  a 
computer  program  such  that  one  HOI  statement  represents  many  machine  language 
instructions. 

Experienced  programmers  in  the  early  50’s  found  that  they  would  generate 
similar  instruction  sequences  often  enough  that  it  proved  useful  to  either  set  aside 
duplicated  blocks  of  cards  to  be  inserted  in  the  program  as  required,  or  in  a  more 
automated  fashion,  to  develop  macros  which  might  be  defined  once  to  the  assembly 
program  and  thereafter  invoked  by  shorthand  notation.  From  such  beginnings  high 
order  languages  were  evolved  as  a  method  for  speeding  up  programming.  The 
extension  and  development  of  this  technique  led  to  the  more  powerful  concept  of  a 
higher  level  of  programming  language. 

The  first  truly  successful  high  order  language  was  FORTRAN.  It  was 
developed  for  the  IBM- 704  and  in  the  original  version  most  of  its  constructs  were 
identical  to  those  commonly  employed  by  machine  language  programmers  for  that 
machine;  in  some  sense,  it  was  inspired  by  this  specific  machine.  But  in  addition,  the 
constructs  were  sufficiently  general  that  it  could  be  adapted  fairly  easily  to  other 
machines  and  the  practical  reality  emerged  the  first  time  of  constructing  a  program 
which  was  machine  independent,  even  across  manufacturers.  So  powerful  was  this 
concept  at  the  time  that  in  the  early  60rs  the  use  of  such  high  order  languages  was 
heralded  as  automatic  programming.(Annual  Review  of  Automatic  Programming, 
Pergamon  Press,  Oxford,  19S0, 1 96 1,  1963, 1964,  etc.) 

In  1959  a  meeting  was  held  in  the  Pentagon  to  establish  a  common 
business-oriented  language,  the  outcome  of  which  was  COBOL  (Programming 
Languages:  History  and  Fundamentals,  Jean  E.  Sammet,  Prentice-Hall,  Edgewood 
Cliffs,  N.J.  1969).  Other  similar  attempts  at  fairly  general  languages  such  as 
ALGOL,  as  well  as  those  designed  for  a  more  specialized  users  such  as  CMS-2  or 
JOVIAL  have  found  their  somewhat  smaller  niche  in  the  marketplace. 

Even  higher  level  specialized  languages  have  come  into  existence  such  as 
GPSS  or  SIMSCRIPT  for  simulation  programs,  or  ATLAS  for  automatic  test  equipment. 
These  are  problem-specific  applications  packages  which  may  be  generated  through 
the  use  of  one  of  the  other  high  order  language  programming  languages  and  are  not  in 
the  range  of  the  present  effort. 

By  high  order  language,  this  report  will  mean  a  computer  programming 
language  of  the  general  level  of  COBOL  or  FORTRAN  primarily  designed  for 
programmers  to  communicate  with  computers.  It  is  non-problem  specific  and  should 
be  able  to  exercise  almost  all  of  the  capability  normally  used  by  those  programming 
in  machine  language  and  at  a  reduction  of  an  order  of  magnitude  in  the  number  of 
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statements  necessary.  The  language  is  relatively  machine  independent, 
representing  possible  logical  constructs  rather  than  specific  hardware  function,  and 
is  translated  by  a  compiler  into  machine  code  to  be  run  on  a  target  machine. 
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III.  General  Goals 

In  this  section  are  listed  the  general  goals  of  a  DoD  software  program.  Some 
of  the  ways  in  which  these  impact  on  the  detailed  desired  language  characteristics 
set  out  in  the  next  section  are  illustrated. 

These  goals,  and  the  point  of  view  they  indicate,  are  generated  by  the 
chalenges  of  the  Defense  Systems  Community  which  is  concerned  with  what  may  be 
loosely  termed  Embedded  Computer  Resources.  They  have  a  fair  overlap  with,  but 
a  different  emphisis  from,  those  of  the  Automatic  Data  Processing  Community. 

There  is  no  real  attempt  to  order  or  weigh  these  goals  at  this  point  nor  is 
there  any  claim  that  the  list  is  complete.  It  is  merely  a  very  brief  summary  of 
discussions  taking  place  during  the  evolution  of  the  requirements. 
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COST 

The  overriding  goal  of  all  technology  and  standardization  programs  are  to 
reduce  the  cost  of  Defense  systems.  Software  is  an  area  in  which  there  are  great 
opportunities  in  cost  savings  which  can  be  brought  about  through  actions  of  the  DoD. 
Computer  hardware  savings  are  much  more  difficult  to  generate.  Since  the 
Department  of  Defense  represents  only  a  very  small  fraction  of  the  computer 
hardware  market,  it  must  effectively  content  itself  with  the  off-shoots  of  the 
mainstream  of  computer  technology.  On  the  other  hand,  the  DoD  is  the  main 
customer  for  software;  and  the  major  support  for  basic  computer  science  and 
technology.  It  is,  therefore  in  a  position  to  influence  the  state-of-the-art  and  to 
materially  change  the  software  development  process.  A  number  of  managerial 
initiatives  to  this  end  are  presently  under  development.  Many  of  them,  including  the 
setting  up  of  libraries  for  software  exchange,  building  up  of  a  tool  environment  for 
improved  software  production  facilities,  distribution  of  government  furnished  tools, 
encouragement  of  the  use  of  high  order  languages  for  maintenance  ease,  etc.,  depend 
upon,  or  will  be  facilitated  by,  restriction  to  a  minimal  number  of  common  high  order 
languages. 

Much  of  each  new  software  system  is  repetitive  of  processes  that  have  been 
written  before.  A  few  new  ideas  may  be  added,  linkages  may  be  changed,  but  the 
bulk  of  the  work  is  not  new.  Yet,  most  systems  are  started  from  scratch  with  little 
dependence  on  previous  work  other  than  what  the  individual  programmers  might 
remember.  There  is  little  high  order  language  commonality.  A  new  language  or 
dialect ,  or  at  least  an  incompatible  compiler  is  often  generated  for  each  project  and  it 
is  impossible  to  sustain  the  creation  of  a  truly  powerful  production  environment. 

Facilities  are  often  locked  into  one  particular  computer  because  of  the  great 
expense  of  transferring  software  to  the  new  machine.  There  are  several  proposals 
and  on-going  work  in  the  DoD  concerning  the  facilities  for  the  translation  of  software 
just  in  a  commercial-like  environment.  This  problem  and  its  implications  may  be  far 
more  serious  in  some  of  our  more  specialized  applications.  A  fully  supported  and 
controlled  common  language  facility  would  eliminate  most  of  these  difficulties  and 
provide  more  flexibility  to  the  managers  to  computer  resources. 
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RESPONSIVENESS  AND  TIMELINESS 

By  its  very  nature,  software  is  plagued  with  underestimates.  It  represents  a 
major  fraction  of  the  total  systems  capability,  but  is  physically  insignificant.  There 
are  no  power  requirements,  no  drop  tests,  no  critical  materials  consumed.  It  is 
basically  unsubstantive,  at  best,  a  few  bits  on  a  magnetic  tape.  It  is  by  nature  easy 
and  quick  to  change  and,  by  implication,  it  is  difficult  to  imagine  how  it  can  be  lengthy 
to  produce.  While  it  is  easy  to  change,  it  is  sometimes  very  hard  to  make  it  correct, 
as  opposed  to  just  different.  As  a  result,  estimates  of  the  time  to  complete  a  project 
are  often  overly  optimistic,  sometimes  so  much  so  that  the  hardware  is  ready  before 
the  software.  The  cost  of  such  delays  is  not  just  the  extra  man  hours  to  bring  the 
software  into  shape,  but  must  be  computed  on  the  loss  of  the  entire  system  during  the 
period  of  delay.  The  technology  then  does  not  exist  for  accurately  estimating 
software  schedules  other  than  by  experience  and  analogy.  Language  can  only 
contribute  to  this  in  that  it  is  a  part  of  a  stable  software  production  environment. 

An  actual  reduction  in  the  time  to  produce  software  would  be  possible  if  the 
language  reduced  the  coding  time  of  the  project.  The  mere  existence  of  the  high 
order  language  normally  reduces  this  coding  time  by  a  fair  amount  and  certain 
language  features  may  act  to  improve  this.  One  must  remember,  however,  that  the 
coding  portion  of  a  large  project  normally  represents  only  ten  or  fifteen  percent  of 
the  total  time  involved  and  the  promotion  of  writing  ease  must,  therefore,  be 
weighted  with  other  portions  of  the  program  production  cycle.  A  major  fraction  of 
this  cycle,  sometimes  up  to  half,  is  involved  with  debugging  and  checking  and, 
therefore,  the  thrust  to  more  reliable  code  must  be  stronger. 

Specification  and  design  is  a  similarly  large  fraction  of  the  effort  and  factors 
such  as  modularity  which  simplify  the  design  are  also  important.  The  overriding 
consideration  must,  however,  be  the  possibility  of  eliminating  most  of  the  effort 
altogether  through  reusing  portions  of  both  code  and  design  which  have  been  done 
before.  The  ability  to  draw  upon  large  amounts  of  past  work,  either  through 
libraries,  previous  experience,  or  automatic  programming  tools,  offer  the  greatest 
possibility  for  payoff  in  timeliness  and  responsiveness. 

It  must  be  pointed  out  that  this  thrust  towards  transportability  emphasizes 
language  transportability  because  the  elements  to  be  transported  are  individual 
subprograms  and  routines,  not  necessarily  systems  concepts  or  coupling  schemea. 
It  is  the  lack  of  acceptance  of  the  possibility  of  using  previously  designed  and 
certified  piece  parts  which  separates  present  day  hardware  and  software  methods. 


RELIABILITY 


Perhaps  the  most  characteristically  military  requirement  for  DoD  software  is 
reliability.  While  all  gradations  of  this  exist  in  the  DoD,  certainly  the  combination  of 
extreme  complexity  in  systems,  some  almost  untestable,  and  the  life  and  death 
implications,  not  just  of  individuals  but  of  millions,  must  be  unique.  This  reliability 
requirement  is  reflected  in  verification,  validation,  and  certification  during  the 
production  process,  as  well  as  back-up  in  alternate  systems,  safeguards,  etc.  A 
significant  portion  of  the  software  cost  is  tied  up  in  this  thrust,  although  often  very 
subtly.  Language  characteristics  which  promote  the  production  of  reliable  code 
must  be  weighted  very  highly. 

Commonality  allowing  the  reuse  of  previously  certified  blocks  of  code  is  also 
of  importance.  Unfortunately,  the  technology  does  not  exist  to  automatically  prove 
the  correctness  of  code  at  a  usable  level.  Should  it  eventually  be  possible  to  prove 
that  a  code  will  do  exactly  what  it  is  intended  to  do  and  also,  as  in  the  security 
question,  will  not  do  anything  that  is  not  intended,  the  language  features  which  make 
this  possible  would  have  very  high  priority  in  the  DoD.  Until  then,  perhaps  the  best 
we  can  do  is  make  available  facilities  for  investigation  and  experiments  in  this 
direction. 

Other  features  promoting  reliability  in  the  DoD  programming  environment, 
would  be  simplicity  and  unambiguity  of  the  language  and  readability  of  the  constructs. 
It  has  been  suggested  that  certain  new  programming  techniques  inherently  produce 
better  and  more  reliable  code.  A  language  should  make  it  possible  to  use  such 
techniques,  although  the  brunt  of  enforcement  must  be  on  the  programming 
management  environment. 
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MAINTAINABILITY 

A  major  portion  of  Defense  cost  in  software  systems  occurs  during  the 
maintenance  phase.  These  systems  are  often  very  long  lived,  which  is  to  be 
expected  from  their  size  and  complexity  and  interaction  with  other  systems.  They 
must  be  kept  viable  for  upwards  of  twenty  years  during  which  time  major  changes 
can  take  place  in  the  threat,  the  employment  concept,  and  even  portions  of  the 
hardware.  As  a  result,  maintenance  is  often  a  blanket  for  continued  development 
and  improvement. 

At  the  present  time  the  statistics  are  somewhat  deceptive  in  this  area.  On 
the  basis  of  perhaps  inadequate  data,  one  would  estimate  that  twice  as  much  is  now 
being  spent  on  development  as  on  maintenance.  However,  this  figure  is  badly 
distorted  in  that  the  largest  systems  are  still  under  development,  while  those  in 
maintenance  were  those  produced  in  much  less  ambitious  times.  The  inventory  is 
still  growing  rapidly,  when  it  stabalizes,one  might  expect  to  see  a  reversal  of  the 
ratio.  In  most  individual  systems,  the  Operations  and  Maintenance  costs  exceed 
those  for  Development  and  Acquisition  by  several  times. 

Over  the  maintenance  period,  the  responsibility  for  the  program  will  pass 
through  many  hands  both  individually  and  corporately,  between  contractor  and 
government  organizations.  Over  time  and  with  each  transition,  knowledge  is  lost. 
The  more  readable  and  definitive  the  program,  the  better  knowledge  will  be 
transmitted.  Transportability  of  the  main  program  is  usually  not  a  question  in  this 
phase,  but  transportability  in  machine  independence  of  the  tools  necessary  to 
maintain  and  support  that  program  are  vital  as  the  facilities  used  in  this  maintenance 
will  change  much  more  rapidly  than  will  the  main  system  hardware.  Likewise,  one  of 
the  main  tools  is  the  personnel  involved.  Reduction  of  the  total  number  of  languages 
with  which  one  must  work  with  will  increase  the  efficiency  and  the  reliability  of  the 
maintenance  effort.  Documentation  of  all  sorts  is  most  important  in  this  phase. 
Whatever  characteristics  of  the  language  that  promote  or  support  documentation, 
internal  or  external,  will  contribute  to  maintainability.  A  certain  amount  of 
self-documentation  results  just  from  the  use  of  a  high  order  language.  Modularity 
and  structured  programming  can  further  aid.  Modern  techniques  in  this  area  must  be 
available. 


TRAINING 


Training  is  a  difficult  factor  to  quantify.  Formal  courses  are  only  a  very  small 
fraction  of  the  training  that  a  programmer  gets.  The  bulk  of  it  is  in  the  form  of 
on-job-training  or  simply  experience.  In  many  cases,  for  instance,  scientific 
programming,  the  training  is  woefully  inadequate  or  even  non-existent.  The 
disparity  in  the  productivity  between  programmers  may,  in  many  cases,  be  traced  to 
inadequate  training.  Better  than  the  productivity  measure  would  be  the  cost 
resulting  from  poorly  written  programs.  Reduction  of  the  number  of  languages  in  use 
would  simplify  the  training  burden. 

It  might  be  argued,  particularly  by  expert  programmers,  that  transitioning  to  a 
new  language  is  fairly  simple  and  should  only  take  a  few  days  of  study  and  practice. 
They  would  then  argue  against  paying  any  penalty.  Unfortunately,  a  census  of  the 
active  programmers  on  DoD  projects,  whether  in-house  or  contract,  would  uncover 
only  a  small  minority  of  such  versatile  experts.  The  average  programmer  is  often 
tied  to  a  single  language  and,  at  that,  not  completely  proficient  in  its  techniques  and 
tools. 


The  training  burden  would  also  argue  for  a  simple  language  with  a  minimum  of 
unambiguous  constructs.  Ideally,  the  constructs  would  fail  soft  so  that  ignorance  of  a 
facility  would  simply  deny  that  facility  and  not  result  in  unexpected  side  affects. 
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TRANSPORTABILITY 

One  of  the  two  main  technical  advantages  of  high  order  languages  in  general  is 
transportability,  sometimes  termed  "machine  independence."  The  advantage  of  being 
able  to  write  a  program  in  sufficiently  general  form  that  it  could  be  compiled  on  to 
more  than  one  computer  is  appealing  for  a  number  of  reasons.  One  can  transfer 
capabilities  developed  in  one  project  to  another  working  on  different  equipment,  and 
one  can  expect  greater  lifetime  for  software  when  it  can  be  carried  on  from  one 
generation  of  machine  to  the  next  in  the  same  installation.  Both  of  these  advantages 
are  clear  cut  and  everyone  with  a  few  years  of  software  experience  has  its  own 
examples  to  cite  in  this  regard. 

The  language  requirements  associated  with  transportability  depend  on  the 
situation.  In  the  very  early  days  of  SHARE,  the  only  really  large-scale  computer  was 
the  7 04  and  a  great  deal  of  interchange  took  place  for  programs  written  with  fairly 
standard  interfaces  in  machine  language.  This  was  entirely  adequate  for  that  time. 
The  present  diversity  of  machines  requires  a  different  technique.  The  use  of  high 
order  language  and  compiling  down  to  machine  code  makes  a  certain  amount  of 
machine  independence  possible  but  not  necessarily  inevitable.  Any  good  high  order 
language  should  lend  itself  to  efficient  compilers  for  most  any  machine.  With 
appropriate  linking  mechanisms,  programs  from  various  languages  could  be  put 
together  as  required.  Unfortunately,  the  practical  world  intervenes  and  the 
production  of  good  compilers  for  every  language  and  every  machine  is  not  a 
reasonable  expectation,  nor  is  sufficient  familiarity  on  the  part  of  majority  of 
programmers  with  a  large  number  of  languages.  To  make  the  overall  software 
environment  relatively  machine  independent  therefore  requires  a  minimal  number  of 
high  order  languages  with  reasonably  general  constructs  and  active  support  for  wide 
availability  of  tools  and  compilers.  This  would  further  suggest  that  high  order 
language  compilers  written  in  that  high  order  language  would  be  most  appropriate. 

One  of  the  snares  that  has  appeared  in  the  past  inhibiting  transportability  has 
been  the  occurrence  of  incompatible  implementations  of  a  single  high  order  language. 
A  language  might  be  insufficiently  or  ambiguously  specified  such  that  different 
implementers  making  decisions  in  an  uncontrolled  fashion  produce  incompatible 
implementations.  Further,  each  one  may  have  his  own  ideas  for  additions  to  the 
defined  language  or  perhaps  may  invoke  subsets  leaving  out  more  difficult  to 
implement  or  momentarily  unnecessary  features.  We  have  examples  of  literally 
dozens  of  different  implementations  of  a  single  language.  These  are  the  cruelest 
mockery  of  language  commonality.  Differences  are  sometimes  so  subtle  as  to  be 
difficult  to  find  and  lead  to  undiscovered  catastrophes.  Such  experiences  give 
programmers  an  almost  paranoid  skepticism  of  claims  of  transportability.  To  make 
transportability  a  reality  will,  therefore,  require  not  only  a  rigid  and  unambiguous 
language  specification,  but  control  or  denial  of  subsets  and  supersets  and  rigorous 
certification  of  all  implementations.  It  will  further  require  the  widespread  availablity 
of  such  certified  compilers  for  many  machines. 


The  payoff  from  transportability  could  be  enormous.  Many  programming 
chores  are  simply  redoing  things  which  have  been  done  before.  Each  project 
usually  only  adds  a  small  fraction  to  the  sum  total  of  knowledge.  If  it  could  draw 
upon  past  work,  cost,  timeliness  and,  reliability,  would  all  be  markedly  improved.  So 
far  from  reality  is  this  today  that  the  techniques  involving  libraries,  etc.,  have  not 
been  worked  out.  A  common  high  order  language  is  simply  one  step,  albeit  an 
important  one,  towards  this  goal. 
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READABILITY /WR1TAB1L1TY 

The  other  major  advantage  initially  claimed  for  high  order  languages  was  that 
they  were  easier  to  read  and  write,  being  closer  to  natural  language  than  is  machine 
code.  Claims  in  this  direction  were  sometimes  carried  to  an  extreme  and  some  were 
promoted  so  highly  that  their  advocates  would  have  you  believe  that  the  coder  need 
not  know  anything  about  the  machine,  simply  write  out  the  requirements  in  English. 
History  does  not  always  support  these  claims.  Many  such  languages  advocated  on 
this  basis  now  are  the  ones  who  have  the  most  specialized  programmers  as  their 
users.  The  DoO  environment  is  sufficiently  large  and  specialized  that  the  allocation 
of  personnel  specifically  for  software  is  the  rule  anyway  and  there  is  no  strong 
requirement  to  eliminate  other  specialists  in  this  area.  This  is  in  contradistinction  to 
a  very  small  commercial  firm  which  may  have  insufficient  demands  to  justify  a 
full-time  programming  staff. 

Our  requirement  for  readability  and  writability  is  therefore  primarily  among 
specialists.  The  desire  to  communicate  with  a  computer  system  in  natural  language 
is  an  entirely  different  one  in  the  DoD  and  involves  query  languages  or  applications 
programs  outside  the  scope  of  this  high  order  language  effort. 

Readability  is  clearly  more  important  to  the  DoD  than  writability.  The 
program  is  written  once,  but  may  have  to  be  read  dozens  of  times  over  over  a  period 
of  years  for  verification,  modification,  etc.  This  is  certainly  true  all  weapons  systems 
applications  and  even  most  of  our  scientific  and  simulation  programs  are  very  long 
lived.  This  requirement  is  very  much  different  from  one  which  might  be  generated, 
for  instance,  in  a  university  environment  when  a  program  may  have  a  life  of  only  a 
few  months  and  a  single  person  working  on  it. 

Ease  of  writing  is  not  an  inconsiderable  goal  but  one  which  may  be  promoted 
through  intelligent  terminals,  preprocessors,  interactive  systems,  etc.  The  language 
evaluation  should  favor  readability  where  conflict  arises. 


EFFICIENCY 


Efficiency  is  probably  the  one  overriding  consideration  on  which  high  order 
languages  stand  or  fall.  Whether  it  be  in  runtime  speed  or  memory  requirements, 
these  quantifiable  costs  of  using  a  high  order  language  in  preference  to  machine 
language  or  assembly  code  is  almost  universally  cited  as  reason  for  rejecting  HOL  in  a 
project.  Often  a  detailed  study  of  the  matter  is  not  accomplished,  so  strong  do 
feelings  run  on  this  subject.  Many  changes  have  taken  in  place  in  the  technology  in 
recent  years  so  as  to  reduce  the  importance  of  this  matter,  but  it  is  still  such  an 
emotion-charged  issue  that  it  must  be  recognized  as  the  principle  customer  concern. 

Much  of  the  pressure  that  existed  some  years  ago  towards  efficiency  is  no 
longer  relevant.  In  former  times  the  cost  of  memory  was  such  a  large  fraction  of  the 
total  system  expenditure  that  it  might  seem  reasonable  to  sacrifice  many  other 
advantages  in  order  to  obtain  memory  efficiency.  This  can  no  longer  be  said  to  be 
the  case.  Software,  particularly  the  maintenance  portion,  is  becoming  much  more 
important  than  the  hardware.  Hardware  costs  are  falling  at  such  a  rate  that  the 
change  in  technology  over  just  a  few  months  can  decrease  the  effective  cost  of 
memory  enough  to  offset  any  loss  in  efficiency,  while  the  cost  of  going  to  machine 
code  might  result  in  a  much  longer  delay  in  developing  the  program.  Likewise,  in 
speed  there  is  often  a  penalty  to  pay  which  is  invariably  judged  so  high,  often  on  the 
basis  of  experience  with  bad  language  implementations,  that  is  common  folklore  that 
"HOL  cannot  be  used  in  real-time  applications"  or  that  one  must  at  least  have  the 
capability  of  dropping  down  into  machine  code  for  "time-critical"  portions  of  the 
system.  Yet  the  cost  of  increasing  the  central  processor  hardware  capability  by 
some  appropriate  amount  may  be  far  less  than  the  software  burden  incurred. 

While  the  cost  arguments  for  HOL  are  valid,  they  do  not  take  into  account 
some  of  the  realities  of  system  procurements.  It  has  been  common  in  the  past  that 
the  hardware  configuration  is  determined  very  early  in  the  process  and  the  software 
must  be  made  to  fit.  Under  these  conditions,  particularly  when  life  cycle  cost  is  not 
an  effective  control,  there  is  little  choice  for  the  project  manager  but  to  be  driven  to 
efficiency.  A  similar  situation  may  arise  in  the  later  phases  of  system  life  when  a 
new  threat  or  other  additional  burden  must  be  accommodated  within  existing 
hardware. 

What  measures  of  efficiency  are  reasonable?  Normally,  one  thinks  in  terms  of 
a  few  tens  of  percent.  An  implementation  that  is  within  ten  percent  of  assembly 
language  code  in  speed  of  execution  or  memory  occupied  would  be  difficult  to 
distinguish,  the  differences  in  the  quality  of  code  produced  by  even  very  good 
programmers  is  probably  greater  than  this.  (In  comparisons  one  only  cites  very 
good  programmers.  Many  current  implementations  may  be  as  good  as  an  average 
programmer.  Further,  one  must  measure  against  code  which  is  written  in  a 
production  environment  to  be  maintainable,  etc.,  not  using  extraordinarily  obscure 
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techniques.  Unique  machine  dependencies  may  still  require  machine  code  inserts.)  A 
thirty  percent  penalty  might  be  appropriate  in  some  situations  and  justified  in  a 
sufficiently  detailed  examination  of  all  costs.  A  fifty  percent  degradation  for  going  to 
high  order  language  may  be  unacceptable  for  a  project  in  which  the  efficiency  of  the 
project  code  was  of  significance.  These  figures  may  be  overly  severe  from  a  strictly 
statistical  view  considering  that  the  logic  of  a  code  may  admit  to  programmer 
variations  much  greater  than  these,  and  large  improvements  in  speed  efficiency 
speed  must  be  sought  there.  Nevertheless,  there  is  no  justification  for  adding  on  an 
additional  excessive  penalty,  particularly  when  the  high  order  language  can  be  very 
efficient.  To  illustrate  that  an  HOL  can  be  efficient,  take  as  an  extreme  example  the 
technique  of  defining  the  program  logic  in  a  high  order  language  which  is  then 
compiled  by  hand,  a  technique  which  has  proved  useful  in  the  early  phases  of  some 
projects.  Presumably,  the  compilation  in  such  a  case  should  be  very  good.  There 
are  even  now  examples  of  benchmarks  for  which  HOL  compilations  are  better  than 
assembly  code.  These  may  be  spurious  cases,  but  in  the  end  this  is  to  be  expected 
theoretically  since  the  HOL  route  gives  a  more  practical  vehicle  for  large-scale 
optimization. 

One  of  the  main  difficulties  with  many  existing  high  order  languages  is  that 
their  implementations  have  often  been  poor,  particularly  languages  generated  for 
single  projects  and  languages  implemented  in  a  short  time  with  limited  resources.  It 
is  not  surprising  that  the  implementation  is  not  as  powerful  as  that  which  could  be 
obtained  if  10  or  100  times  more  effort  could  be  devoted  to  its  development  and  to 
the  tools  and  techniques  for  its  use.  Such  powerful  implementations  are  very  good 
and  optimize  better  than  the  average  programmer.  Assuming  a  very  minimal  number 
of  well-supported  languages  for  the  Department  of  Defense,  one  could  devote 
sufficient  effort  to  provide  the  tools  and  compilers  to  produce  very  efficient  object 
code.  It  is  not  clear  that  any  other  language  requirement  mitigates  against  this 
expectation. 

This  particular  requirement,  or  solution,  would  reinforce  the  thrust  to 
commonality  by  making  it  attractive  to  reduce  not  only  the  number  of  languages 
supported  but  a  number  of  different  compiler  approaches  and  would  call  for  the  type 
of  control  of  the  language  which  would  promote  large  efforts  for  tools  and  compilers. 
A  contributing  technological  trend  is  for  DoD  programs,  particularly  those  which  are 
the  most  critical  real-time  programs,  is  to  have  available  very  large  computers  on 
which  to  build  the  system,  even  though  it  may  eventually  run  on  a  small  computer. 
The  large  systems  can  support  cross  compilers  which  are  much  more  powerful  than 
those  self-hosted  on  a  smaller  target  machine.  While  this  is  not  yet  a  universal 
procedure,  it  certainly  provides  a  further  opportunity  to  bring  to  bear  tools  to 
promote  efficient  programs.  In  such  a  case,  the  requirement  on  the  high  order 
language  is  to  give  as  much  information  to  the  compiler  as  possible  without  overly 
restricting  its  options.  This  argument  is  contrary  to  the  current  practice  of  providing 
small  subsets  of  a  high  order  language  for  mini-computers.  Such  a  subset  would 
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only  restrict  the  amount  of  information  available  to  a  compiler  and  would,  of 
necessity,  produce  a  less  efficient  code.  The  computer  might  produce  even  poorer 
code  if  forced  to  host  on  a  small-target  machine. 
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ACCEPTABILITY 

No  language  is  going  to  be  of  value  unless  it  is  used  There  are  many  tangible 
and  intangible  influences  which  will  determine  its  final  acceptability.  The  large  scale 
acceptability  of  compilers  is  certainly  the  most  influential  tangible  asset.  Perhaps 
the  only  factor  that  this  influences  in  language  design  should  be  the  ability  to  write 
compilers  in  the  high  order  language. 

That  the  language  resembles  something  the  customer  is  already  familiar  with 
is  certainly  going  to  be  of  considerable  importance.  Arbitrary  decisions  on  formats 
must  be  take  in  the  direction  of  existing  DoD  practice.  The  possibility  of  making 
translators  from  existing  programming  languages  to  common  languages  will  probably 
never  appear  specifically  as  a  requirement,  since  there  is  no  intent  at  this  time  to 
perform  such  translations.  However,  it  would  be  difficult  to  deny  the  attractiveness 
of  such  a  possibility  if  it  existed. 
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IV.  Needed  Characteristics 

The  set  of  characteristics  prescribed  below  represent  a  synthesis  of  the 
requirements  submitted  by  the  Military  Departments  and  are  intended  to  be 
consistent  with  the  general  goals  of  Section  III,  to  be  self-consistent,  and  to  be 
achievable  with  existing  computer  software  and  hardware  technology.  The  needed 
characteristics  are  the  requirements  to  be  satisfied  by  an  existing,  modified  or  new 
language  which  is  selected  as  a  Common  HOL.  They  prescribe  capabilities  and 
properties  which  a  common  DoD  language  should  possess  but  are  not  intended  to 
impose  any  particular  language  features  or  mechanization  of  those  capabilities.  The 
header  of  each  item  gives  a  general  description  of  the  needed  language 
characteristic  while  the  subsequent  paragraph(s)  of  its  body  provide  clarification, 
discuss  some  of  the  implications  and  problems,  provide  the  rationale  behind  its 
inclusion,  and/or  further  detail  the  requirement.  The  entire  text  and  not  just  the 
headers  constitute  the  requirements. 

The  large  number  of  characteristics  reflects  an  attempt  at  thoroughness  in 
dealing  with  the  relevant  issues.  Similarly,  the  length  of  the  discussion  for  many 
items  reflects  the  need  to  resolve  the  ambiguities,  examine  the  implications,  and 
demonstrate  the  feasibility  of  the  compendious  statement  introducing  that 
characteristic.  Because  the  characteristics  address  issues  in  the  design, 
implementation,  and  use  of  the  language  and  properties  of  the  resulting  product, 
there  should  be  no  correlation  between  the  number  of  characteristics  discussed  here 
and  the  number  of  features  in  a  language  which  satisifes  these  characteristics. 
Many  of  the  characteristics  will  influence  the  choice  of  many  features,  and  every 
feature  will  be  influenced  by  many  of  the  needed  characteristics.  Good  language 
design  is  a  unification  process.  Any  language  which  satisfies  these  characteristics 
must  be  smaller  and  simpler  than  the  set  of  issues  underlying  its  choice. 

The  material  reported  in  the  last  three  sections  (K,L,M)  was  generated  by  the 
Services  at  the  same  time  as  the  technical  characteristics,  but  is  concerned  with 
translators,  support  software,  documentation,  training,  standards,  application 
libraries,  management  policy,  and  procurement  practices  for  the  common  language 
and  its  use.  These  issues  are  important.  While  mistakes  and  oversights  in  the 
technical  characteristics  can  guarantee  failure  of  the  common  language  effort, 
success  is  not  guaranteed  no  matter  how  technically  meritorious  the  resulting 
language.  Success  can  only  be  guaranteed  by  close  attention  to  a  variety  of 
administrative  issues,  including  those  considered  below. 

Several  of  these  issues,  including  those  of  implementation,  documentation,  and 
support  will  either  directly  or  indirectly  affect  the  acceptability  of  candidate 
languages.  As  with  the  needed  technical  characteristics  for  the  common  language, 
the  issues  raised  here  are  often  not  resolved  at  the  most  detailed  level.  Until  more 
detailed  characteristics  of  the  language  come  into  focus  there  is  no  rationale  with 
which  to  resolve  all  these  issues  in  detail. 
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A.  DATA  AND  TYPES 

1.  Typed  Language 

2.  Data  Types 

3.  Precision 

4.  Fixed  Point  Numbers 

5.  Character  Data 

6.  Arrays 

7.  Records 


Al.  The  language  will  be  typed.  The  type  (or  mode)  of  all  variables, 
components  of  composite  data  structures,  expressions,  operations,  and 
parameters  will  be  determinable  at  compile  time  and  unalterable  at  run  time. 
The  language  will  require  that  the  type  of  each  variable,  and  component  of 
composite  data  structures  be  explicitly  specified  in  the  source  programs. 

By  the  type  of  a  data  object  is  meant  the  set  of  objects  themselves,  the 
essential  properties  of  those  objects  and  the  set  of  operations  which  give  access  to 
and  take  advantage  of  those  properties.  The  author  of  any  correct  program  in  any 
programming  language  must,  of  course,  know  the  types  of  all  data  and  variables  used 
in  his  programs.  If  the  program  is  to  be  maintainable,  modifiable  and 
comprehensible  by  someone  other  than  its  author,  the  the  types  of  variables, 
operations,  and  expressions  should  be  easily  determined  from  the  source  program. 
Type  specifications  in  programs  provide  the  redundancy  necessary  to  verify 
automatically  that  the  programmer  has  adhered  to  his  own  type  conventions.  Static 
type  definitions  also  provide  information  at  compile  time  necessary  for  production  of 
efficient  object  code.  Compile  time  determination  of  types  does  not  preclude  the 
inclusion  of  language  structures  for  dynamic  discrimination  among  alternative  record 
formats  (see  A7)  or  among  components  of  a  union  type  (see  E6).  Where  the  subtype 
or  record  structure  cannot  be  determined  until  run  time,  it  should  still  be  fully 
discriminated  in  the  program  text  so  that  all  the  type  checks  can  be  completed  at 
compile  time. 


A2.  The  language  will  provide  data  types  for  integer,  real  (floating  point  and 
fixed  point),  Boolean  and  character  and  will  provide  arrays  (i.e.,  composite 
data  structures  with  indexable  components  of  homogeneous  type)  and 
records  (i.e.,  composite  data  structures  with  labeled  components  of 
heterogeneous  type)  as  type  generators. 

These  are  the  common  data  types  and  type  generators  of  most  programming 
languages  and  object  machines.  They  are  sufficient,  when  used  with  a  data 
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definition  facility  (see  E6,  D6,  and  J 1),  to  efficiently  mechanize  other  desired  types 
such  as  complex  or  vector. 


A3.  The  source  language  will  require  global  (to  a  scope)  specification  of  the 
precision  for  floating  point  arithmetic  and  will  permit  precision  specification 
for  individual  variables.  This  specification  will  be  interpreted  as  the 
maximum  precision  required  by  the  program  logic  and  the  minimum  precision 
to  be  supported  by  the  object  code. 

This  is  a  specification  of  what  the  program  needs,  not  what  the  hardware 
provides.  Machine  independence,  in  the  use  of  approximate  value  numbers  (usually 
with  floating  point  representation),  can  be  achieved  only  if  the  user  can  place 
constraints  on  the  translator  and  object  machine  without  forcing  a  specific 
mechanization  of  the  arithmetic.  Precision  specifications,  as  the  minimum  supported 
by  the  object  code,  provide  all  the  power  and  guarantees  needed  by  the  programmer 
without  unnecessarily  constraining  the  object  machine  realization.  Precision 
specifications  will  not  change  the  type  of  reals  nor  the  set  of  applicable  operations. 
Precison  specifications  apply  to  arithmetic  operations  as  well  as  to  the  data  and 
therefore  should  be  specified  once  for  a  designated  scope.  This  permits  different 
precisions  to  be  used  in  different  parts  of  a  program.  Specification  of  the  precision 
will  also  contribute  to  the  legibility  end  implemen tability  of  programs. 


A4.  Fixed  point  numbers  will  be  treated  as  exact  quantities  which  have  a 
range  and  a  fractional  step  size  which  are  determined  by  the  user  at  compile 
time.  Scale  factor  management  will  be  done  by  the  compiler. 

Scaled  integers  are  useful  approximations  to  real  numbers  when  dealing  with 
exact  quantity  fractional  values,  when  the  object  machine  does  not  have  floating 
point  hardware,  and  when  greater  precision  is  required  than  is  available  with  the 
floating  point  hardware.  Integers  will  also  be  treated  as  exact  quantities  with  a  step 
size  equal  to  one. 


A5.  Character  sets  will  be  treated  as  any  other  enumeration  type. 

Like  any  other  data  type  defined  by  enumeration  (see  E6),  it  should  be 
possible  to  specify  the  program  literal  and  order  of  characters.  These  properties  of 
the  character  set  would  be  unalterable  at  run  time.  The  definition  of  a  character  set 
should  reflect  on  the  manner  it  is  used  within  a  program  and  not  necessarily  on  the 
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print  representation  a  particular  physical  device  associates  with  a  bit  pattern  at  run 
time.  In  general,  unless  all  devices  use  the  same  character  code,  run-time 
translation  between  character  sets  will  be  required.  Widely  used  character  sets, 
such  as,  USASCII  and  EBCDIC  will  be  available  in  a  standard  library.  Note  that 
access  to  a  linear  array  filled  with  the  characters  of  an  alphabet,  A,  and  indexed  by 
an  alphabet,  B,  will  convert  strings  of  characters  from  B  to  A. 


A6.  The  language  will  require  user  specification  of  the  number  of 
dimensions,  the  range  of  subscript  values  for  each  dimension,  and  the  type  of 
each  array  component.  The  number  of  dimensions,  the  type  and  the  lower 
subscript  bound  will  be  determinable  at  compile  time.  The  upper  subscript 
bound  will  be  determinable  at  entry  to  the  array  allocation  scope. 

This  is  general  enough  to  permit  both  arrays  which  can  be  allocated  at 
compile  or  load  time  and  arrays  which  can  be  allocated  at  scope  entry,  but  does  not 
permit  dynamic  change  to  the  size  of  constructed  arrays.  It  is  sufficient  to  permit 
allocation  of  space  pools  which  the  user  can  manage  for  allocation  of  more  complex 
data  structures  including  dynamic  arrays.  The  range  of  subscript  values  for  any 
given  dimension  will  be  a  contiguous  subsequence  of  values  from  an  enumeration 
type  (including  integers).  The  preferable  lower  bound  on  the  subscript  range  will  be 
the  initial  element  of  an  enumeration  type  or  zero,  because  it  often  contributes  to 
program  efficiency  and  clarity. 


A 7.  The  language  will  permit  records  to  have  alternative  structures,  each  of 
which  is  fixed  at  compile  time.  The  name  and  type  of  each  record  component 
will  be  specified  by  the  user  at  compile  time. 

This  provides  all  that  is  safe  to  use  in  CMS-2  and  JOVIAL  OVERLAY  and  in 
FORTRAN  EQUIVALENCE.  It  permits  hierarchically  structured  data  of 
heterogeneous  type,  permits  records  to  have  alternative  structures  as  long  as  each 
structure  is  fixed  at  compile  time  and  the  choice  is  fully  discriminated  at  run  time,  but 
it  does  not  permit  arbitrary  references  to  memory  nor  the  dropping  of  type  checking 
when  handling  overlayed  structures.  The  discrimination  condition  will  not  be 
restricted  to  a  field  of  the  record  but  should  be  any  expression. 
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B.  OPERATIONS 

1.  Assignment  and  Reference 

2.  Equivalence 

3.  Relational 

4.  Arithmetic  Operations 

5.  Truncation  and  Rounding 

6.  Boolean  Operations 

7.  Scalar  Operations 

8.  Type  Conversion 

9.  Changes  in  Numeric  Representation 

10.  I/O  Operations 

1 1.  Power  Set  Operations 


Bl.  Assignment  and  reference  operation  will  be  automatically  defined  for  all 
data  types  which  do  not  manage  their  data  sto.  age.  The  assignment 
operation  will  permit  any  value  of  a  given  type  to  be  assigned  to  a  variable, 
array  or  record  component  of  that  type  or  of  a  union  type  containing  that  type. 
Reference  will  retrieve  the  last  assigned  value. 

The  user  will  be  able  to  declare  variables  for  all  data  types.  Variables  are 
useful  only  when  there  are  corresponding  access  and  assignment  operations.  The 
user  will  be  permitted  to  define  assignment  and  access  operations  as  part  of 
encapsulated  type  definitions  (see  E5).  Otherwise,  they  will  be  automatically 
defined  for  types  which  do  not  manage  the  storage  for  their  data.  (See  D6  for 
further  discussion). 


B2.  The  source  language  will  have  a  built-in  operation  which  can  be  used  to 
compare  any  two  data  objects  (regardless  of  type)  for  identity. 

Equivalence  is  an  essential  universal  operation  which  should  not  be  subject  to 
restriction  on  its  use.  There  are  many  useful  equivalence  operations  for  some  types 
and  a  language  definition  cannot  foresee  all  these  for  user  defined  types. 
Equivalence  meaning  logical  identity  and  not  bit-by-bit  comparison  on  the  internal 
data  representation,  however,  is  required  for  all  data  types.  Proper  semantic 
interpretation  of  identity  requires  that  equality  and  identity  be  the  same  for  atomic 
data  (i.e.,  numbers,  characters,  Boolean  values,  and  types  defined  by  enumeration) 
and  that  elements  of  a  disjoint  types  never  be  identical.  Consequently,  its  usefulness 
at  run  time  is  restricted  to  data  of  the  same  type  or  to  types  with  nonempty 
intersections.  For  floating  point  numbers  identity  will  be  defined  as  the  same  within 
the  specified  (minimum)  precision. 
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B3.  Relational  operations  will  be  automatically  defined  for  numeric  data  and 
all  types  defined  by  enumeration. 

Numbers  and  types  defined  by  enumeration  have  an  obvious  ordering  which 
should  be  available  through  relational  operations.  All  six  relational  operations  will 
be  included.  It  will  be  possible  to  inhibit  ordering  definitions  when  unordered  sets 
are  intended. 


B4.  The  built-in  arithmetic  operations  will  include:  addition,  subtraction, 
multiplication,  division  (with  a  real  result),  exponentiation,  integer  division 
(with  integer  or  fixed  point  arguments  and  remainder),  and  negation. 

These  are  the  most  widely  used  numeric  operations  and  are  available  as 
hardware  operations  in  most  machines.  Floating  point  operations  will  be  precise  to 
at  least  the  specified  precision. 


B5.  Arithmetic  and  assignment  operations  on  data  which  are  within  the 
range  specifications  of  the  program  will  never  truncate  the  most  significant 
digits  of  a  numeric  quantity.  Truncation  and  rounding  will  always  be  on  the 
least  significant  digits  and  will  never  be  implicit  for  integers  and  fixed  point 
numbers.  Implicit  rounding  beyond  the  specified  precision  will  be  allowed 
for  floating  point  numbers. 

These  requirements  seem  obvious,  particularly  for  floating  point  numbers  and 
yet  many  of  our  existing  languages  truncate  the  most  significant  mantissa  digits  in 
some  mixed  and  floating  point  operations. 


B6.  The  built-in  Boolean  operations  will  include  "and,  "  "or,  ”  "not,  "  and 
"nor."  The  operations  "and"  and  "or"  on  scalars  will  be  evaluated  in  short 
circuit  mode. 

Short  circuit  mode  as  used  here  is  a  semantic  rather  than  an  implementation 
distinction  and  means  that  "and"  and  "or"  are  in  fact  control  operations  which  do  not 
evaluate  side  effects  of  their  second  argument  if  the  value  of  the  first  argument  is 
"false"  or  "true,  "  respectively.  Short  circuit  evaluation  has  no  disadvantages  over 
the  corresponding  computational  operations,  sometimes  produces  faster  executing 
code  in  languages  where  the  user  can  rely  on  the  short  circuit  execution,  and 
improves  the  clarity  and  maintainability  of  programs  by  permitting  expressions  such 
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as,  "i<«7  &  A[i]  >x"  which  could  be  erroneous  were  short  circuit  execution  not 
intended.  Note  that  the  equivalence  and  nonequivalence  operations  (see  B2)  are  the 
same  as  logical  equivalence  and  exclusive-or  respectively. 


B7.  The  source  language  will  permit  scalar  operations  and  assignment  on 
conformable  arrays  and  will  permit  data  transfers  between  records  or  arrays 
of  identical  logical  structure. 

Conformabiiity  will  require  exactly  the  same  number  of  components  (although 
a  scalar  can  be  considered  compatible  with  any  array)  and  one  for  one  compatibility 
in  type.  Correspondence  will  be  by  position  in  similarly  shaped  arrays.  In  many 
situations  component  by  component  operations  are  done  on  array  elements.  In  fact, 
a  primary  reason  for  having  arrays  is  to  permit  large  numbers  of  similarly  treated 
objects  to  have  a  uniform  notation.  Operations  on  data  aggregates  available  directly 
in  the  source  language  hide  the  details  of  the  sequencing  and  thereby,  simplify  the 
program  and  make  more  optimizations  available.  In  addition,  they  permit 
simultaneous  execution  on  machines  with  parallel  processing  hardware.  Although 
component  by  component  operations  will  be  available  for  built-in  composite  data 
structures  which  are  used  to  define  application-oriented  structures,  that  capability 
will  not  be  automatically  inherited  by  defined  data  structures.  A  matrix  might  be 
defined  using  an  array,  but  it  will  not  inherit  the  array  operations  automatically. 
Multiplication  for  matrices  would,  for  example,  be  unnatural,  confusing  and 
inconvenient  if  the  product  operator  for  matrices  were  interpreted  as  a  component 
by  component  operation  instead  of  cross  product  of  corresponding  row  and  column 
vectors.  Component  by  component  operations  also  allow  operations  on  character 
strings  represented  as  vectors  of  characters  and  allow  efficient  Boolean  vector 
operations. 

Transfers  between  arrays  or  records  of  identical  logical  structure  are 
necessary  to  permit  efficient  run  time  conversion  from  one  object  representation  to 
another,  as  might  be  done  when  data  is  packed  to  reduce  peripheral  storage 
requirements  and  I/O  transfer  times  but  need  to  be  unpacked  locally  to  minimize 
processing  costs. 


B8.  There  will  be  no  implicit  type  conversions  but  no  conversion  operation 
will  be  required  when  the  type  of  an  actual  parameter  is  a  constituent  of  a 
union  type  which  is  the  formal  parameter.  The  language  will  provide  explicit 
conversions  operations  among  integer,  fixed  point  and  floating  point  data, 
between  the  object  representation  of  numbers  and  their  representations  as 
characters,  and  between  fixed  point  scale  factors. 
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Implicit  type  conversions  which  represent  changes  in  the  value  of  data  items 
without  an  explicit  indicator  in  the  program,  are  not  only  error  prone  but  can  result  in 
unexpected  run  time  overhead. 


B9.  Explicit  conversion  operations  will  not  be  required  between  numerical 
ranges.  There  will  be  a  run  time  exception  condition  when  any  integer  or 
fixed  point  value  is  truncated. 

Because  ranges  do  not  form  closed  systems,  range  validation  is  not  possible  at 
compile  time  (e.g.,  T-l+1"  may  be  a  range  error).  At  best,  the  compiler  might  point 
out  likely  range  errors.  (This  requirement  is  optional  for  hardware  installations 
which  do  not  have  overflow  detection). 


BIO.  The  base  language  will  provide  operations  allowing  programs  to 
interact  with  files,  channels  or  devices  including  terminals.  These  operations 
will  permit  sending  and  receiving  both  data  and  control  information,  will 
enable  programs  to  dynamically  assign  and  reassign  I/O  devices,  will  provide 
user  control  for  exception  conditions,  and  will  not  be  installation  dependent. 

Whether  the  referenced  "files”  are  real  or  virtual  and  whether  they  are 
hardware  devices,  I/O  channels  or  logical  files  depends  on  the  object  machine 
configuration  and  on  the  details  of  its  operating  system  if  present.  But  in  any 
programming  system  I/O  operations  ultimately  reduce  to  sending  or  receiving  data 
and/or  control  information  to  a  file  or  to  a  device  controller.  These  can  be  made 
accessible  in  a  HOL  in  an  abstract  form  through  a  small  set  of  generic  I/O  operations 
(like  "read"  and  "write,  "  with  appropriate  device  and  exception  parameters).  Note 
that  devices  and  files  are  similar  in  many  respects  to  types,  so  additional  language 
features  may  not  be  required  to  satisfy  this  requirement.  This  requirement,  in 
conjunction  with  requirement  El,  permits  user  definition  of  unique  equipment  and  its 
associated  I/O  operations  as  data  types  within  the  syntactic  and  semantic  framework 
provided  by  the  generic  operations. 


B 1 1.  The  language  will  provide  operations  on  data  types  defined  as  power 
sets  of  enumeration  types  (see  E6).  Th  c*  operations  will  include  union, 
intersection,  difference,  complement,  and  an  element  predicate. 


As  with  any  data  type,  power  sets  will  be  useful  only  if  there  are  operations 
which  can  create,  select  and  interrogate  them  Note  that  this  provides  only  a  very 
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special  class  of  sets  but  one  which  is  very  useful  for  computations  on  sets  of 
indicators,  flags,  and  similar  devices  in  monitoring  and  control  applications.  More 
general  sets  if  desired,  must  be  defined  using  the  type  definition  facilities. 
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C.  EXPRESSIONS  AND  PARAMETERS 

1.  Side  Effects 

2.  Operand  Structure 

3.  Expressions  Permitted 

4.  Constant  Expressions 

5.  Consistent  Parameter  Rules 

6.  Type  Agreement  in  Parameters 

7.  Formal  Parameter  Kinds 

8.  Formal  Parameter  Specifications 

9.  Variable  Numbers  of  Parameters 


Cl.  Side  effects  which  are  dependent  on  the  evaluation  order  among  the 
arguments  of  an  expression  will  be  evaluated  left-to-right. 

This  is  a  semantic  restriction  on  the  evaluation  order  of  arguments  to 
expressions.  It  provides  an  explicit  rule  (i.e.,  left-to-right)  for  order  of  argument 
evaluation,  but  allows  the  implementations  to  alter  the  actual  order  in  any  way  which 
does  not  change  the  effect.  This  provides  the  user  with  a  simple  rule  for 
determining  the  effects  of  interactions  among  argument  evaluations  without  imposing 
a  strict  rule  on  compilers  which  are  sophisticated  enough  to  detect  potential 
side-effects  and  optimize  through  reordering  of  arguments  when  the  evaluation 
order  does  not  affect  the  result.  Control  operations  (e.g.,  conditional  and  iterative 
control  structures),  of  course,  must  be  exceptions  to  this  general  rule  since  control 
operations  are  in  fact  those  operations  which  specify  the  sequencing  and  evaluation 
rules  for  their  arguments. 


C2.  Which  parts  of  an  expression  constitute  the  operands  to  each  operation 
within  that  expression  should  be  obvious  to  the  reader.  There  will  be  few 
levels  of  operator  hierarchy  and  they  will  be  widely  recognized. 

Care  must  be  taken  to  ensure  that  the  operator/operand  structure  of 
expressions  is  not  psychologically  ambiguous  (i.e.,  to  guarantee  that  the  parse 
implemented  by  the  language  is  the  same  as  intended  by  the  programmer  and 
understood  by  those  reading  the  program).  This  kind  of  problem  can  be  minimized 
by  having  few  precedence  levels  and  parsing  rules  by  allowing  explicit  parentheses 
to  specify  the  intended  execution  order,  and  by  requiring  explicit  parentheses  when 
the  execution  order  is  of  significance  to  the  result  within  the  same  precedence  level 
(e.g.,  "X  divided  by  Y  divided  by  1"  and  "X  divided  by  Y  multiplied  by  Z").  The  user 
will  not  be  able  to  define  new  operator  precedence  rules  nor  change  the  precedence 
of  existing  operators. 
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C3.  Expressions  of  a  given  type  will  be  permitted  anywhere  in  source 
programs  where  both  constants  and  references  to  variables  of  that  type  are 
allowed. 

This  is  an  example  of  not  imposing  arbitrary  restrictions  and  special  case 
rules  on  the  user  of  the  source  language.  Special  mention  is  made  here  only  because 
so  many  languages  do  restrict  the  form  of  expressions.  FORTRAN,  for  example,  has 
a  list  of  seven  different  syntactic  forms  for  subscript  expressions,  instead  of  allowing 
all  forms  of  arithmetic  expressions. 


C4.  Constant  expressions  will  be  allowed  in  programs  anywhere  constants 
are  allowed,  and  constant  expressions  will  be  evaluated  before  run  time. 

The  ability  to  write  constant  expressions  in  programs  has  proven  valuable  in 
languages  with  this  capability,  particularly  with  regard  to  program  readability  and  in 
avoiding  programmer  error  in  externally  evaluating  and  transcribing  constant 
expressions.  They  are  most  often  used  in  declarations.  There  is  no  need,  however, 
that  constant  expressions  impose  run  time  costs  for  their  evaluation.  They  can  be 
evaluated  once  at  compile  time  or  if  this  is  inconvenient  because  of  incompatibilities 
between  the  host  and  object  machines,  the  compiler  can  generate  code  for  their 
evaluation  at  load  time.  In  any  case,  the  resulting  value  should  be  the  same  (at  least 
within  the  stated  precision)  regardless  of  the  object  machine  (see  D2).  Allowing 
constant  expressions  in  place  of  constants  can  improve  the  clarity,  correctness  and 
maintainability  of  programs  and  does  not  impose  any  run  time  costs. 


C5.  There  will  be  a  consistent  set  of  rules  applicable  to  all  parameters, 
whether  they  be  for  procedures,  for  types  for  exception  handing,  for  parallel 
processes,  for  declarations,  or  for  built-in  operators.  There  will  be  no 
special  operations  (e.g.,  array  substructuring)  applicable  only  to  parameters. 
Uniformity  and  consistency  contributes  to  ease  of  learning, 

implementing  and  using  a  language;  allows  the  user  to  concentrate  on  the 
programming  task  instead  of  the  language;  and  leads  to  more  readable, 
understandable,  and  predictable  programs. 


C6.  Formal  and  actual  parameters  will  always  agree  in  type.  The  number  of 
dimensions  for  array  parameters  will  be  determinable  at  compile  time.  The 
size  and  subscript  range  for  array  parameters  need  not  be  determinable  at 
compile  time,  but  can  be  passed  as  part  of  the  parameter. 
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Type  transfers  hidden  in  procedure  calls  with  incompatible  formal  and  actual 
parameters  whether  intentional  or  accidental  have  long  been  a  source  of  program 
errors  and  of  programs  which  are  difficult  to  maintain.  On  the  other  hand,  there  is  no 
reason  why  the  subscript  ranges  for  arrays  cannot  be  passed  as  part  of  the 
arguments.  Some  notations  permit  such  parameters  to  be  implicit  on  the  call  side. 
Formal  parameters  of  a  union  type  will  be  considered  conformable  to  actual 
parameters  of  any  of  the  component  types. 


C7.  There  will  be  only  four  classes  of  formal  parameters.  For  data  there 
will  be  those  which  act  as  constants  representing  the  actual  parameter  value 
at  the  time  of  call,  and  those  which  rename  the  actual  parameter  which  must 
be  a  variable.  In  addition,  there  will  be  a  formal  parameter  class  for 
specifying  the  control  action  when  exception  conditions  occur  and  a  class  for 
procedure  parameters. 

The  first  class  of  data  parameter  acts  as  a  constant  within  the  procedure  body 
and  cannot  be  assigned  to  nor  changed  during  the  procedures  execution;  its 
corresponding  actual  parameter  may  be  any  legal  expression  of  the  desired  type  and 
will  be  evaluated  once  at  the  time  of  call.  The  second  class  of  data  parameter 
renames  the  actual  parameter  which  must  be  a  variable,  the  address  of  the  actual 
parameter  variable  will  be  determined  by  (or  at)  the  time  of  call  and  unalterable 
during  execution  of  the  procedure,  and  assignment  (or  reference)  to  the  formal 
parameter  name  will  assign  (or  access)  the  variable  which  is  the  actual  parameter. 
These  are  the  only  two  widely  used  parameter  passing  mechanisms  for  data  and  the 
many  alternatives  (at  least  10  have  been  suggested)  add  complexity  and  cost  to  a 
language  without  sufficiently  increasing  the  clarity  or  power.  A  language  with 
exception  handling  capability  must  have  a  way  to  pass  control  and  related  data 
through  procedure  call  interfaces.  Exception  handling  control  parameters  will  be 
specified  on  the  call  side  only  when  needed.  Actual  procedure  parameters  will  be 
restricted  to  those  of  similar  (explicit  or  implicit)  specification  parts. 


C8.  Specification  of  the  type,  range,  precision,  dimension,  scale  and  format  of 
parameters  will  be  optional  in  the  procedure  declaration.  None  of  them  will 
be  alterable  at  run  time. 

Optional  formal  parameter  specification  permits  the  writing  of  generic 
procedures  which  are  instantiated  at  compile  time  by  the  characteristics  of  their 
actual  parameters.  It  eliminates  the  need  for  compile  time  "type"  parameters.  This 
generic  procedure  capability,  for  example,  allows  the  definition  of  stacks  and  queues 
and  their  associated  operations  on  data  of  any  given  type  without  knowing  the  data 
type  when  the  operations  are  defined. 
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C9.  There  will  be  provision  for  variable  numbers  of  arguments,  but  in  such 
cases  all  but  a  constant  number  of  them  must  be  of  the  same  type.  Whether  a 
routine  can  have  a  variable  number  of  arguments  must  be  determinable  from 
its  description  and  the  number  of  arguments  for  any  call  will  be  determinable 
at  compile  time. 

There  are  many  useful  purposes  for  procedures  with  variable  numbers  of 
arguments.  These  include  intrinsic  functions  such  as  "print,"  generalizations  of 
operations  which  are  both  commutative  and  associative  such  as  "max"  and  "min,"  and 
repetitive  application  of  the  same  binary  operation  such  as  the  Lisp  "list"  operation. 
The  use  of  variable  number  of  argument  operations  need  not  and  will  not  cause 
relaxation  of  any  compile  time  checks,  require  use  of  multiple  entry  procedures  allow 
the  number  of  actual  parameters  to  vary  at  run  time,  nor  require  special  calling 
mechanisms.  If  the  parameters  which  can  vary  are  limited  to  a  program  specified 
type  treated  as  any  other  argument  on  the  call  side  and  as  elements  of  an  array  within 
the  procedure  definition,  full  type  checking  can  be  done  at  compile  time.  There  will 
be  not  prohibition  on  writing  a  special  case  of  a  procedure  for  a  particular  number  of 
arguments. 
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D.  VARIABLES,  LITERALS  AND  CONSTANTS 

1.  Constant  Value  Identifiers 

2.  Numeric  Literals 

3.  Initial  Values  of  Variables 

4.  Numeric  Range  and  Step  Size 

5.  Variable  Types 

6.  Pointer  Variables 


Dl.  The  user  will  have  the  ability  to  associate  constant  values  of  any  type 
with  identifiers. 

The  use  of  identifiers  to  represent  constant  values  has  often  made  programs 
more  readable,  more  easily  modifiable  and  less  prone  to  error  when  the  value  of  a 
constant  is  changed.  Associating  constant  values  with  an  identifier  is  preferable  to 
assigning  the  value  to  a  variable  because  it  is  then  clearly  marked  in  the  program  as  a 
constant,  can  be  automatically  checked  for  unintentional  changes,  and  often  can  have 
a  more  efficient  object  representation. 


D2.  The  language  will  provide  a  syntax  and  a  consistent  interpretation  for 
constants  of  built-in  data  types.  Numeric  constants  will  have  the  same  value 
(within  the  specified  precision)  in  both  programs  and  data  (input  or  output). 

Literals  are  needed  for  all  atomic  data  types  and  should  be  provided  as  part  of 
the  language  definition  for  built-in  types.  Regardless  of  the  source  of  the  data  and 
regardless  of  the  object  machine  the  value  of  constants  should  be  the  same.  For 
integers  it  should  be  exact  and  for  reals  it  should  be  the  same  within  the  specified 
precision.  Compiler  writers,  however,  would  disagree.  They  object  to  this 
requirement  on  two  grounds:  that  it  is  too  costly  if  the  host  and  object  machines  are 
rT  different  and  that  it  is  unnecessary  if  they  are  the  same.  In  fact,  all  costs  are  at 

k  compile  time  and  must  be  insignificant  compared  to  the  life  time  costs  resulting  from 

-*•  object  cope  containing  the  wrong  constant  values.  As  for  being  unnecessary,  there 

have  been  all  too  many  cases  of  different  values  from  program  and  data  literals  on 
the  same  machine  because  the  compile  time  and  run  time  conversion  packages  were 
•  different  and  imprecise. 


D3.  The  language  will  permit  the  user  to  specify  the  initial  values  of 
individual  variables  as  part  of  their  declaration.  Such  variables  will  be 
initialized  at  the  time  of  their  apparent  allocation  (i.e.,  at  entry  to  allocation 
scope).  There  will  be  no  default  initial  values. 
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The  ability  to  initialize  variables  at  the  time  of  their  allocation  will  contribute 
to  program  clarity,  but  a  requirement  to  do  so  would  be  an  arbitrary  and  sometimes 
costly  decision  to  the  user.  Default  initial  values  on  the  other  hand,  contribute  to 
neither  program  clarity  nor  correctness  and  can  be  even  more  costly  at  run  time.  It 
is  usually  a  programming  error  if  a  variable  is  accessed  before  it  is  initialized.  It  is 
desirable  that  the  translator  give  a  warning  when  a  path  between  the  declaration  and 
use  of  a  variable  omits  initialization.  Whether  a  variable  will  be  assigned  is  in 
general  an  unsolvabie  problem,  but  it  is  sometimes  determinable  whether 
assignments  occur  on  potential  paths.  In  the  case  of  arrays,  it  it  possible  at  compile 
time  only  to  determine  that  some  components  (but  not  necessarily  which)  have  been 
initialized.  There  will  be  provision  (at  user  option)  for  run  time  testing  for 
initialization. 


D4.  The  source  language  will  require  its  users  to  specify  individually  the 
range  of  all  numeric  variables  and  the  step  size  for  fixed  point  variables.  The 
range  specifications  will  be  interpreted  as  the  maximal  specifications  will  be 
interpreted  as  the  maximal  range  of  values  which  will  be  assigned  to  a 
variable  and  the  minimal  range  which  must  be  supported  by  the  object  code. 
Range  and  step  size  specifications  will  not  be  interpreted  as  defining  new 
types. 

Range  specifications  are  a  special  form  of  assertion.  They  aid  in 
understanding  and  determining  the  correctness  of  programs.  They  can  also  be  used 
as  additional  information  by  the  compiler  in  deciding  what  storage  and  allocation  to 
use  (e.g.,  half  words  might  be  more  efficient  for  integers  in  the  range  0  to  1000). 
Range  specifications  also  offer  the  opportunity  for  the  translator  to  insert  range  tests 
automatically  for  run  time  or  debug  time  validation  of  the  program  logic.  With  the 
ranges  of  variables  specified  in  the  program,  it  becomes  possible  to  perform  many 
subscript  bounds  checks  at  compile  time.  These  bounds,  checks,  however,  can  be 
only  as  valid  as  the  range  specifications  which  cannot  in  general  be  validated  at 
compile  time.  Range  specifications  on  approximate  valued  variables  (usually  with 
floating  point  implemetation)  also  offer  the  possibility  of  their  implementation  using 
fixed  point  hardware. 


05.  The  range  of  values  which  can  be  associated  with  a  variable,  array,  or 
record  component  will  be  any  built-in  type,  any  defined  type  or  a  contiguous 
subsequence  of  any  enumeration  type. 

There  should  not  be  any  arbitrary  restrictions  on  the  structure  of  data.  This 
permits  arrays  to  be  components  of  records  or  arrays  and  permits  records  to  be 
components  of  arrays. 


33 


D6.  The  language  will  provide  a  pointer  mechanism  which  can  be  used  to 
build  data  with  shared  and/or  recursive  substructure.  The  pointer  property 
will  only  affect  the  use  of  variables  (including  array  and  record  components) 
of  some  data  types.  Pointer  variables  will  be  as  safe  in  their  use  as  are  any 
other  variables. 

Assignment  to  a  pointer  variable  will  mean  that  the  variable’s  name  is  to  act  as 
an  additional  label  (or  reference)  on  the  datum  being  assigned.  Assignment  to  a 
nonpointer  variable  will  mean  that  the  variable’s  name  it  to  label  a  copy  of  the  object 
being  assigned.  For  data  without  alterable  component  structure  or  alterable 
component  values,  there  is  no  functional  difference  between  reference  to  multiple 
copies  and  multiple  references  to  a  single  copy.  Consequently,  pointer/nonpointer 
will  be  a  property  only  of  variables  for  composite  types  and  of  composite  array  and 
record  components  Because  the  pointer/nonpointer  property  applies  to  all  variables 
of  a  given  type,  it  will  be  specified  as  part  of  the  type  definition.  The  use  of  pointers 
will  be  kept  safe  by  prohibiting  pointers  to  data  structures  whose  allocation  scope  is 
narrower  than  that  of  the  pointer  variable. 

Such  a  restriction  is  easily  enforced  at  compile  time  using  hierarchical  scope 
rules  providing  there  is  no  way  to  dynamically  create  new  instances  of  the  data  type. 
In  the  latter  case,  the  dynamically  created  data  can  be  allocated  with  full  safety  using 
a  (user  or  library  defined)  space  pool  which  is  either  local  (i.e.,  own)  or  global  to  the 
type  definition.  If  variables  of  a  type  do  not  have  the  pointer  property  then  dynamic 
storage  allocation  would  be  required  for  assignment  unless  their  size  is  constant  and 
known  at  the  time  of  variable  allocation.  Thus,  the  nonpointer  property  will  be 
permitted  only  for  types  (a)  whose  data  have  a  structure  and  size  which  is  constant  in 
the  type  definition  or  (b)  which  manage  the  storage  for  their  data  as  part  of  the  type 
definition.  Because  pointers  are  often  less  expensive  at  run  time  than  nonpointers 
and  are  subject  to  fewer  restrictions,  the  specification  of  the  nonpointer  property 
will  be  explicit  in  programs  (this  is  similar  to  the  Algol-60  issue  concerning  the 
explicit  specification  of  "value"  (i.e.,  nonpointer)  and  "name"  (i.e.  pointer).  The  need 
for  pointers  is  obvious  in  building  data  structures  with  shared  or  recursive 
substructures;  such  as,  directed  graphs,  stacks,  queues,  and  list  structures. 
Providing  pointers  as  absolute  address  types,  however,  produces  gaps  in  the  type 
checking  and  scope  mechanisms.  Type  and  access  restricted  pointers  will  provide 
the  power  of  general  pointers  without  their  undesirable  characteristics. 
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E.  DEFINITION  FACILITIES 

1.  User  Definitions  Possible 

2.  Consistent  Use  of  Types 

3.  No  Default  Declarations 

4.  Can  Extend  Existing  Operators 

5.  Type  Definitions 

6.  Data  Defining  Mechanisms 

7.  No  Free  Union  or  Subset  Types 

8.  Type  Initialization 


El.  The  user  of  the  language  will  be  able  to  define  new  data  types  and 

operations  within  programs. 

The  number  of  specialized  capabilities  needed  for  a  common  language  is  large 
and  diverse.  In  many  cases,  there  is  no  consensus  as  to  the  form  these  capabilities 
should  take  in  a  programming  language.  The  operational  requirements  dictating 
specific  specialized  language  capabilities  are  volatile  and  future  needs  cannot  always 
be  foreseen.  No  language  can  make  available  all  the  features  useful  to  the  broad 
spectrum  of  military  applications,  anticipate  future  applications  and  requirements  or 
even  provide  a  universally  "best"  capability  in  support  of  a  single  application  area. 
A  common  language  needs  capability  for  growth.  It  should  contain  all  the  power 
necessary  to  satisfy  all  the  applications  and  the  ability  to  specialize  that  power  to  the 
particular  application  task.  A  language  with  defining  facilities  for  data  and 
operations  often  makes  it  possible  to  add  new  application-oriented  structures  and  to 
use  new  programming  techniques  and  mechanisms  through  descriptions  written 
entirely  within  the  language.  Definitions  will  have  the  appearance  and  costs  of 
features  which  are  built  into  the  language  while  actually  being  catalogued  accessible 
application  packages.  The  operation  definition  facility  will  include  the  ability  to 
define  new  infix  operators  (but  see  H2  for  restrictions).  No  programming  language 
can  be  all  things  to  all  people,  but  a  language  with  data  and  operation  definition 
facilities  can  be  adapted  to  meet  changing  requirements  in  a  variety  of  areas. 

The  ability  to  define  data  and  operations  is  well  within  the  state  of  the  art. 
Operation  definition  facilities  in  the  form  of  subroutines  have  been  available  in  all 
general  purpose  programming  languages  since  at  least  the  time  of  early  FORTRANs. 
Data  definition  facilities  have  been  available  in  a  variety  of  programming  languages 
for  almost  10  years  and  reached  their  peak  with  a  large  number  of  extensible 
languages(Stephen  A.  Schuman  (Ed.)  Proceedings  of  the  International  Symposium  on 
Extensible  Languages,  S1GPLAN  Notices,  Vol.  6,  No.  12,  December  1971.  Also,  C. 
Christensen  and  C.J.  Shaw  (Ed.),  Proceedings  of  the  Extensible  Language 
Symposium,  SIGPLAN  Notices  4,  August  1969.)  (over  30)  in  1968  and  shortly 
thereafter.  A  trend  toward  more  abstract  and  less  machine-oriented  data 


specification  mechanisms  has  appeared  more  recently  in  PASCAL(Niklaus  Wirth,  "An 
Assessment  of  the  Programming  Language  PASCAL,  "Proceedings  of  the  International 
Conference  on  Reliable  Software  21-23  April  1973,  p.  23-30).  Data  type 
definitions,  with  operations  and  data  defined  together,  are  used  in  several  languages 
including  SIMULA-67(Jacob  Palme,  "SIMULA  as  a  Tool  for  Extensible  Program 
Products,  "SIGPLAN  Notices,  Vol.  9,  No.  4,  February  1974).  On  the  other  hand, 
there  is  currently  much  ferment  as  to  what  is  the  proper  function  and  form  of  data 
type  definitions. 


E2.  The  "use"  of  defined  types  will  be  indistinguishable  from  built-in  types. 

Whether  a  type  is  built-in  or  defined  within  the  base  will  not  be  determinable 
from  its  syntactic  and  semantic  properties.  There  will  be  no  ad  hoc  special  cases 
nor  inconsistent  rules  to  interfere  with  and  complicate  learning,  using  and 
implementing  the  language.  If  built-in  features  and  user  defined  data  structures  and 
operations  are  treated  in  the  same  way  throughout  the  language  so  that  the  base 
language,  standard  application  libraries  and  application  programs  are  treated  in  a 
uniform  manner  by  the  user  and  by  the  translator,  then  these  distinctions  will  grow 
dim  to  everyone’s  advantage.  When  the  language  contains  all  the  essential  power, 
when  few  can  tell  the  difference  between  the  base  language  and  library  definitions, 
and  when  the  introduction  of  new  data  types  and  routines  does  not  impact  the 
compiler  and  the  language  standards,  then  there  is  little  incentive  to  proliferate 
languages.  Similarly,  if  typed  definitions  are  processed  entirely  at  compile  time  and 
the  language  allows  full  program  specification  of  the  internal  representation,  there 
need  be  no  penalty  in  run  time  efficiency  for  using  defined  types. 


E3.  Each  program  component  will  be  defined  in  the  base  language,  in  a 
library,  or  in  the  program.  There  will  be  no  default  declarations. 

As  programmers,  we  should  not  expect  the  translator  to  write  our  programs 
for  us  (at  least  in  the  immediate  future).  If  we  somehow  know  that  the  translator’s 
default  convention  is  compatible  with  our  needs  for  the  case  at  hand  we  should  still 
document  the  choice  so  others  can  understand  and  maintain  our  programs.  Neither 
should  we  be  able  to  delay  definitions  (possibly  forget  them)  until  they  cause  trouble 
in  the  operational  system.  This  is  a  special  case  of  requirement  11. 


E4.  The  user  will  be  able,  within  the  source  language,  to  extend  existing 
operators  to  new  data  types. 


When  an  operation  is  an  abstraction  of  an  existing  operation  for  a  new  type  or 
is  a  generalization  of  an  existing  operation,  it  is  inconvenient,  confusing  and 
misleading  to  use  any  but  the  existing  operator  symbol  or  function  named.  The 
translator  will  not  assume  that  commutativity  of  bulit-in  operations  is  preserved  by 
extensions,  and  any  assumptions  about  the  associativity  of  built-in  or  extended 
operations  will  be  ignored  by  the  translator  when  explicit  parentheses  are  provided 
in  an  expression. 


E5.  Type  definitions  in  the  source  language  will  permit  definition  of  both  the 
class  of  data  objects  comprising  the  type  and  the  set  of  operations  applicable 
to  that  class.  A  defined  type  will  not  automatically  inherit  the  operations  of 
the  data  with  which  it  is  represented. 

Types  define  abstract  data  objects  with  special  properties.  The  data 
objects  are  given  a  representation  in  terms  of  existing  data  structures,  but  they  are 
of  little  value  until  operations  are  available  to  take  advantage  of  their  special 
properties.  When  one  obtains  access  to  a  type,  he  needs  its  operations  as  well  as 
its  data.  Numeric  data  is  needed  in  many  applications  but  is  of  little  value  to  any 
without  arithmetic  operations.  The  definable  operations  will  include  constructors, 
selectors,  predicates,  and  type  conversions. 


E6.  The  data  objects  comprising  a  defined  type  will  be  definable  by 
enumeration  of  their  literal  names,  as  Cartesian  products  of  existing  types 
(i.e.,  as  array  and  record  classes),  by  discriminated  union  (i.e.,  as  the  union  of 
disjoint  types)  and  as  the  power  set  of  an  enumeration  type.  These 
definitions  will  be  processed  entirely  at  compile  time. 

The  above  list  comprises  a  currently  known  set  of  useful  definitional 
mechanisms  for  data  types  which  do  not  require  run  time  support,  as  do  garbage 
collection  and  dynamic  storage  allocation.  In  conjunction  with  pointers  (see  D6), 
they  provide  many  of  the  mechanisms  necessary  to  define  recursive  data  structures 
and  efficient  sparse  data  structures, 


E7.  Type  definitions  by  free  union  (i.e.,  union  of  non-disjoint  types)  and 
subsetting  are  not  desired. 

Free  union  adds  no  new  power  not  provided  by  discriminated  union,  but  does 
require  giving  up  the  security  of  types  in  return  for  programmer  freedom.  Range  and 
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subset  specifications  on  variables  are  useful  documentation  and  debugging  aids,  but 
will  not  be  construed  as  types.  Subsets  do  not  introduce  new  properties  or 
operations  not  available  to  the  superset  and  often  do  not  form  a  closed  system  under 
the  superset  operations,  Unlike  types,  membership  in  subsets  can  be  determined 
only  at  run  time. 


E8.  When  defining  a  type,  the  user  will  be  able  to  specify  the  initialization 
and  finalization  procedures  for  the  type  and  the  actions  to  be  taken  at  the  time 
of  allocation  and  deallocation  of  variables  of  that  type. 

It  is  often  necessary  to  do  bookkeeping  or  to  take  other  special  action  when 
variables  of  a  given  type  are  allocated  or  deallocated.  The  language  will  not  limit  the 
class  of  definable  types  by  withholding  the  ability  to  define  those  actions. 
Initialization  might  take  place  once  when  the  type  is  allocated  (i.e.,  in  its  allocation 
scope)  and  would  be  used  to  set  up  the  procedures  and  initialize  the  variables  which 
are  local  to  the  type  definition.  These  operations  will  be  definable  in  the 
encapsulation  housing  the  rest  of  the  type  definition. 
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F.  SCOPES  AND  LIBRARIES 

1.  Separate  Allocation  and  Access  Allowed 

2.  Limiting  Access  Scope 

3.  Compile  Time  Scope  Determination 

4.  Libraries  Available 

5.  Library  Contents 

6.  Libraries  and  Compools  Indistinguishable 

7.  Standard  Library  Definitions 


FI.  The  language  will  allow  the  user  to  distinguish  between  scope  of 
allocation  and  scope  of  access. 

The  scope  of  allocation  or  lifetime  of  a  program  structure  is  that  region  of  the 
program  for  which  the  object  representation  of  the  structure  should  be  present. 
The  allocation  scope  defines  the  program  scope  for  which  own  variables  of  the 
structure  must  be  maintained  and  identifies  the  time  for  initialization  of  the  structure. 
The  access  scope  defines  the  regions  of  the  program  in  which  the  allocated  structure 
is  accessible  to  the  program  and  will  never  be  wider  than  the  allocation  scope.  In 
some  case.,  the  user  may  desire  that  each  use  of  a  defined  program  structure  be 
independent  (i.e.,  the  allocation  and  accessing  scopes  would  be  identical).  In  other 
cases,  the  various  accessing  scopes  might  share  a  common  allocation  of  the 
structure. 


F2.  The  ability  to  limit  the  access  to  separately  defined  structures  will  be 
available  both  where  the  structure  is  defined  and  where  it  is  used.  It  will  be 
possible  to  associate  new  local  names  with  separately  defined  program 
components. 

Limited  access  specified  in  a  type  definition  is  necessary  to  guarantee  that 
changes  to  data  representations  and  to  management  routines  which  purportedly  do 
not  affect  the  calling  programs  are  in  fact  safe.  By  rigorously  controlling  the  set  of 
operations  applicable  to  a  defined  type,  the  type  definition  guarantees  that  no 
external  use  of  the  type  can  accidentally  or  intentionally  use  hidden  nonessential 
properties  of  the  type.  Renaming  separately  defined  programming  components  is 
necessary  to  avoid  naming  conflicts  when  they  are  used. 

Limited  access  on  the  call  side  provides  a  high  degree  of  safety  and  eliminates 
nonessential  naming  conflicts  without  limiting  the  degree  of  accessibility  which  can 
be  built  into  programs.  The  alternative  notion,  that  all  declarations  which  are 
external  to  a  program  segment  should  have  the  same  scope,  is  inconvenient  and 
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costly  in  creating  large  systems  which  are  composed  from  many  subsystems  because 
it  forces  global  access  scopes  and  the  attendant  naming  conflicts  on  subsystems  not 
using  the  defined  items. 


F3.  The  scope  of  identifiers  will  be  wholly  determined  at  compile  time. 

Identifiers  will  be  declared  at  the  beginning  of  their  scope  and  multiple  use  of 
variable  names  will  not  be  allowed  in  the  same  scope.  Except  as  otherwise 
explicitly  specified  in  programs,  access  scopes  will  be  lexically  embedded  with  the 
most  local  definition  applying  when  the  same  identifier  appears  at  several  levels. 
The  language  will  use  the  above  lexically  embedded  scope  rules  for  declarations  and 
other  definitions  of  identifiers  to  make  them  easy  to  recognize  and  to  avoid  errors 
and  ambiguities  from  multiple  use  of  identifiers  in  a  single  scope. 


F4.  A  variety  of  application-oriented  data  and  operations  will  be  available  in 
libraries  and  easily  accessible  in  the  language. 

A  simple  base  alone  is  not  sufficient  for  a  common  language.  Even  though  in 
theory  such  a  language  provides  the  necessary  power  and  the  capability  for 
specialization  to  particular  applications,  the  users  of  the  language  cannot  be 
expected  to  develop  and  support  common  libraries  under  individual  projects  There 
will  be  broad  support  for  libraries  common  to  users  of  well  recognized  application 
areas.  Application  libraries  will  be  developed  as  early  as  possible. 


F5.  Program  components  not  defined  within  the  current  program  and  not  in 
the  base  language  will  be  maintained  in  compile  time  accessible  libraries. 
The  libraries  will  be  capable  of  holding  anything  definable  in  the  language  and 
will  not  exclude  routines  whose  bodies  are  written  in  other  source  languages. 

The  usefulness  of  a  language  derives  primarily  from  the  existence  and 
accessibility  of  specialized  application-oriented  data  and  operations.  Whether  a 
library  should  contain  source  or  object  code  is  a  question  of  implementation 
efficiency  and  should  not  be  specified  in  the  definition  of  the  source  language,  but  the 
source  language  description  will  always  be  available.  It  should  be  remembered, 
however,  that  interfaces  cannot  be  validated  at  program  assembly  time  without  some 
equivalent  of  their  source  language  interface  specifications,  that  object  modules  are 
machine-dependent  and,  therefore,  not  portable,  that  source  code  is  often  more 
compact  than  object  code,  and  that  compilers  for  simple  languages  can  sometimes 
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compile  faster  than  a  loader  can  load  from  relocatable  object  programs.  Library 
routines  written  on  other  languages  will  not  be  prohibited  provided  the  foreign 
routine  has  object  code  compatible  with  the  calling  mechanisms  used  in  the  Common 
HOL  and  providing  sufficient  header  information  (e  g.,  parameter  types,  form  and 
number)  is  given  with  the  routine  in  Common  HOL  form  to  permit  the  required  compile 
time  checks  at  the  interface. 


F6.  Libraries  and  Compools  will  be  indistinguishable.  They  will  be  capable 
of  holding  anything  definable  in  the  language,  and  it  will  be  possible  to 
associate  them  with  any  level  of  programming  activity  from  systems  through 
projects  to  individual  programs.  There  will  be  many  specialized  compools  or 
libraries  any  user  specified  subset  of  which  is  immediately  accessible  from  a 
given  program. 

Compools  have  proven  very  useful  in  organizing  and  controlling  shared  data 
structures  and  shared  routines.  A  similar  mechanism  will  be  available  to  manage  and 
control  access  to  related  library  definitions. 


F7.  The  source  language  will  contain  standard  machine  independent 
interfaces  to  machine  dependent  capabilities,  including  peripheral  equipment 
and  special  hardware. 

The  convenience,  ease  of  use  and  savings  in  production  and  maintenance 
costs  resulting  from  using  high  order  languages  come  from  being  able  to  use 
specialized  capabilities  without  building  them  from  scratch.  Thus,  it  is  essential  that 
high  level  capabilities  be  supplied  with  the  language.  The  idea  is  not  to  provide  all 
the  many  special  cases  in  the  language,  but  to  provide  a  few  general  case  .  hich  will 
cover  the  special  cases. 

There  is  currently  little  agreement  on  standard  operating  system,  I/O,  or  file 
system  interfaces.  This  does  not  preclude  support  of  one  or  more  forms  for  the  near 
term.  For  the  present  the  important  thing  is  that  one  be  chosen  and  made  available 
as  a  standard  supported  library  definition  which  the  user  can  use  with  confidence. 


41 


G.  CONTROL  STRUCTURES 

1.  Kinds  of  Control  Structures 

2.  The  Go  To 

3.  Conditional  Control 

4.  Iterative  Control 

5.  Routines 

6.  Parallel  Processing 

7.  Exception  Handling 

8.  Synchronization  and  Real  Time 


G 1.  The  language  will  provide  structured  control  mechanisms  for  sequential, 
conditional,  iterative,  and  recursive  control.  It  will  also  provide  control 
structures  for  (pseudo)  parallel  processing,  exception  handling  and 
asynchronous  interrupt  handling. 

These  mechanisms,  hopefully,  provide  a  spanning  set  of  control  structures. 
The  most  appropriate  operations  in  several  of  these  areas  is  an  open  question.  For 
the  present,  the  choice  will  be  a  spanning  set  of  composable  control  primitives  each 
of  which  is  easily  mapped  onto  object  machines  and  which  does  not  impose  run  time 
charges  when  it  is  not  used.  Whether  parallel  processing  is  real  (i.e.,  by 
multiprocessing)  or  is  synthesized  on  a  single  sequential  processor,  is  determined  by 
the  object  machine,  but  if  programs  are  written  as  if  there  is  true  parallel  processing 
(and  no  assumption  about  the  relative  speeds  of  the  processors)  then  the  same 
results  will  be  obtained  independent  of  the  object  environment. 

It  is  desirable  that  the  number  of  primitive  control  structures  in  the  language 
be  minimized,  not  by  reducing  the  power  of  the  language,  but  by  selecting  a  small  set 
of  composable  primitives  which  can  be  used  to  easily  build  other  desired  control 
mechanisms  within  programs.  This  means  that  the  capabilities  of  control 
mechanisms  must  be  separable  so  that  the  user  need  not  pay  either  program  clarity 
or  implementation  costs  for  undesired  specialized  capabilities.  By  these  criteria,  the 
Algol-60  "FOR"  would  be  undesirable  because  it  imposes  the  use  of  a  loop  control 
variable,  requires  that  there  be  a  single  terminal  condition  and  that  the  condition  be 
tested  before  each  iteration.  Consequently,  "FOR”  cannot  be  composed  to  build 
other  useful  iterative  control  structures  (e.g.,  FORTRAN  "DO").  The  ability  to 
compose  control  structures  does  not  imply  an  ability  to  define  new  control  operations 
and  such  an  ability  to  define  new  control  operations,  and  such  an  ability  is  in  conflict 
with  the  limited  parameter  passing  mechanisms  of  C7. 


G2.  The  source  language  will  provide  a  "GO  TO"  operation  applicable  to 
program  labels  within  its  most  local  scope  of  definition. 
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The  "GO  TO"  is  a  machine  level  capability  which  is  still  needed  to  fill  in  any 
gaps  which  might  remain  in  the  choice  of  structured  control  primitives,  to  provide 
compatibility  for  translitterating  programs  written  in  older  languages,  and  because  of 
the  wide  familiarity  of  current  practitioners  with  its  use.  The  language  should  not, 
however,  impose  unnecessary  costs  for  its  presence.  The  "GO  TO"  will  be  limited  to 
explicitly  specified  program  labels  at  the  same  scope  level.  Neither  should  the 
language  provide  specialized  facilities  which  encourage  its  use  in  dangerous  and 
confusing  ways.  Switches,  designational  expressions,  label  variables,  label 
parameters  and  numeric  labels  are  not  desired.  Switches  here  refer  to  the 
unrestricted  switches  which  are  generalizations  of  the  "GO  TO”  and  not  to  case 
statements  which  are  a  general  form  for  conditionals(see  G3).  This  requirements 
should  not  be  interpreted  to  conflict  with  the  specialized  form  of  control  transfer 
provided  by  the  exception  handling  control  structure  of  G7. 


G3.  The  conditional  control  structures  will  be  fully  partitioned  and  will  permit 
selection  among  alternative  computations  based  on  the  value  of  a  Boolean 
expression,  on  the  subtype  of  a  value  from  a  discriminated  union,  or  on  a 
computed  choice  among  labeled  alternatives. 

The  conditional  control  operations  will  be  fully  partitioned  (e.g.,  an  "ELSE" 
clause  must  follow  each  "IF  THEN”)  so  the  choice  is  clear  and  explicit  in  each  case. 
There  will  be  some  general  fori '  of  conditional  which  allows  an  arbitrary  computation 
to  determine  the  selected  situation  (e.g.,  Zahn’s  device(Donald  E.  Knuth,  "Structured 
Programming  with  go  to  Statements, “  ACM  Computer  Surveys,  Vol.  6,  No.  4, 
December  1974)  provides  a  good  solution  to  the  general  problem).  Special 
mechanisms  are  also  needed  for  the  more  common  cases  of  the  Boolean  expression 
(e.g.,  "IF  THEN  ELSE")  and  for  value  or  type  discrimination  (e.g.,  "CASE"  on  one  of  a 
set  of  values  or  subtype  of  a  union). 


G4.  The  iterative  control  structure  will  permit  tho  termination  condition  to 
appear  anywhere  in  the  loop,  will  require  control  variables  t  be  local  to  the 
iterative  control,  will  allow  entry  only  at  the  head  of  the  loop,  and  will  not 
impose  excessive  overhead  in  clarity  or  nji  the  execution  costs  for  common 
special  case  termination  conditions  (e.g.,  fixed  number  of  iterations  or 
elements  of  an  array  exhausted). 

In  its  most  general  form,  a  programmed  loop  is  executed  repetitively  until 
some  computed  predicate  becomes  true.  There  may  be  more  than  one  terminating 
predicate,  and  they  might  appear  anywhere  in  the  loop.  Specialized  control 
structures  (e.g.,  "WHILE  DO”)  have  been  used  for  the  common  situation  in  which  the 
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termination  conditions  precedes  each  iteration.  The  most  common  case  is 
termination  after  a  fixed  number  of  iterations  and  a  specialized  control  structure 
should  be  provided  for  that  purpose  (e.g.,  FORTRAN  "DO"  or  Algol-60  "FOR").  A 
problem  which  arises  in  many  programming  languages  is  that  loop  control  variables 
are  global  to  the  iterative  control  and  thus,  will  have  a  value  after  loop  termination, 
but  that  value  is  usually  an  accident  of  the  implementation.  Specifying  the  meaning  of 
control  variables  after  loop  termination  in  the  language  definition  resolves  the 
ambiguity  but  must  be  an  arbitrary  decision  which  will  not  aide  program  clarity  or 
correctness,  and  may  interfere  with  the  generation  of  efficient  object  code.  Loop 
control  variables  are  by  definition  variables  used  to  control  the  repetitive  execution 
of  a  programmed  loop  and  as  such  will  be  local  to  the  loop  body,  but  at  loop 
termination  it  will  be  possible  to  pass  their  value  (or  any  other  computed  value)  out  of 
the  loop,  conveniently  and  efficiently. 


G5.  Recursive  as  well  as  nonrecursive  routines  will  be  available  in  the 
source  language.  It  will  not  be  possible  to  define  procedures  within  the  body 
of  a  recursive  procedure. 

Recursion  is  desirable  in  many  applications  because  it  contributes  directly  to 
their  elegance  and  clairty  and  simplifies  proof  procedures.  Indirectly,  it  contributes 
to  the  reliability  and  maintainability  of  some  programs.  Recursion  is  required  in 
order  to  avoid  unnecessarily  opaque,  complex  and  confusing  programs  when 
operating  on  recursive  data  structures.  Recursion  has  not  been  widely  used  in  DoD 
software  because  many  programming  languages  do  not  provide  recursion, 
practitioners  are  not  familiar  with  its  use,  and  users  fear  that  its  run  time  costs  are  to 
high.  Of  these,  only  the  run  time  costs  woulc  ji^tify  its  exclusion  from  the  language. 

A  major  run  time  cost  often  attributed  to  recursion  is  the  need  for  the 
presence  of  a  set  of  "display"  registers  which  are  used  to  keep  track  of  the 
addresses  of  the  various  levels  of  lexically  imbedded  environments  and  which  must 
be  managed  and  updated  at  run  time.  The  display,  however,  is  necessary  only  in 
programs  in  which  routines  access  variables  which  are  global  to  their  own  definition, 
but  local  to  a  more  global  recursive  procedure.  This  possibility  can  easily  be 
removed  by  prohibiting  the  definition  of  procedures  within  the  body  of  a  recursive 
procedure.  The  utility  of  such  a  combination  of  capabilities  is  very  questionable,  and 
this  single  restriction  will  eliminate  all  added  execution  costs  for  nonrecursive 
procedures  in  programs  which  contain  recursive  procedures. 

As  with  any  other  facility  of  the  language,  routines  should  be  implemented  in 
the  most  efficient  manner  consistent  with  their  use  and  the  language  should  be 
designed  so  that  efficient  implementations  are  possible.  In  particular,  the  most 
possible  regardless  of  whether  the  language  or  even  the  program  contains  recursive 
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procedures.  When  any  routine  makes  a  procedure  call  as  its  last  operation  before 
exit  (and  this  is  quite  common  for  recursive  routines)  the  implementation  might  use 
the  same  data  area  for  both  routines,  and  do  a  jump  to  the  head  of  the  called 
procedure  thereby  saving  much  of  the  overhead  of  a  procedure  call  and  eliminating  a 
return.  The  choice  between  recursive  and  nonrecursive  routines  involves 
trade-offs.  Recursive  routines  can  aid  program  clarity  when  operating  on  recursive 
data,  but  can  detract  from  clarity  when  operating  on  iterative  data.  They  can 
increase  execution  time  when  procedure  call  overhead  is  greater  than  loop  overhead 
and  can  decrease  execution  times  when  loop  overhead  is  the  more  expensive. 
Finally,  program  storage  for  recursive  routines  is  often  only  a  small  fraction  of  that 
for  a  corresponding  iterative  procedure,  but  the  data  storage  requirements  are  often 
much  larger  because  of  the  simultaneous  presence  of  several  activations  of  the  same 
procedure. 


G6.  The  source  language  will  provide  a  parallel  processing  capability.  This 
capability  should  include  the  ability  to  create  and  terminate  (possibly  pseudo) 
parallel  processes  and  for  these  processes  to  gain  exclusive  use  of  resources 
during  specified  portions  of  their  execution. 

A  parallel  processing  capability  is  essential  in  embedded  computer 
applications.  Programs  must  send  data  to,  receive  data  from,  and  control  many 
devices  which  are  operating  in  parallel.  Multiprogramming  (a  form  of  pseudo 
paralell  processing)  is  necessary  so  that  many  programs  within  a  system  can  meet 
their  differing  real  time  constraints.  The  parallel  processing  capability  will  minimally 
provide  the  ability  to  define  and  call  parallel  processing  and  the  ability  to  gain 
exclusive  use  of  system  resources  in  the  form  of  data  structures,  devices  and  pseudo 
devices.  This  latter  ability  satisfies  one  of  the  two  needs  for  synchronization  of 
parallel  processes.  The  other  is  required  in  conjunction  with  real  time  constraints 
(see  G8). 

The  parallel  processing  capability  will  be  defined  as  true  parallel  (as  opposed 
to  coroutine)  primitives,  but  with  the  understanding  that  in  most  implementations  the 
object  computer  will  have  fewer  processors  (usually  one)  than  the  number  of  parallel 
paths  specified  in  a  program.  Interleaved  execution  in  the  implementation  may  be 
required. 

The  parallel  processing  features  of  the  language  should  be  selected  to 
eliminate  any  unnecessary  overhead  associated  with  their  use.  The  costs  of  parallel 
processes  are  primarily  n  run  time  storage  management.  As  with  recursive  routines 
most  accessing  and  storage  management  problems  can  be  eliminated  by  prohibiting 
complex  interactions  with  other  language  facilities  where  the  combination  has  little  if 
any  utility.  In  particular,  it  will  not  be  possible  to  define  a  parallel  routine  within  the 
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body  of  a  recursive  routine  and  it  will  not  be  possible  to  define  any  routine  including 
parallel  routines  within  the  body  of  those  parallel  routines  which  can  have  multiple 
simultaneous  activations.  If  the  language  permits  several  simultaneous  activations  of 
a  given  parallel  process  then  it  might  require  the  user  to  give  a  upper  bound  on  the 
number  which  can  exist  simultaneously.  The  latter  requirement  is  reasonable  for 
parallel  processes  because  it  is  information  known  by  the  programmer  and 
necessary  to  the  maintainer,  because  parallel  processes  cannot  normally  be  stacked, 
and  because  it  is  necessary  for  the  compilation  of  efficient  programs. 


G7.  The  exception  handing  control  structure  will  permit  the  user  to  cause 
transfer  of  control  and  data  for  any  error  or  exception  situation  which  might 
occur  in  a  program. 

It  is  essential  in  many  aplications  that  there  be  no  program  halts  beyond  the 
user’s  control.  The  user  must  be  able  to  specify  the  action  to  be  taken  on  any 
exception  situation  which  might  occur  within  his  program.  The  exception  handling 
mechanism  will  be  parameterized  so  data  can  be  passed  to  the  recovery  point. 
Exception  situations  might  include  arithmetic  overflow,  exhaustion  of  available  space, 
hardware  errors,  any  user  defined  exceptions  and  any  run  time  detected 
programming  error. 

The  user  will  be  able  to  write  programs  which  can  get  out  of  an  arbitrary  nest 
of  control  and  intercept  it  at  any  embedding  level  desired.  The  exception  handling 
mechanism  will  permit  the  user  to  specify  the  action  to  be  taken  upon  the  occurrence 
of  a  designated  exception  within  any  given  access  scope  of  the  program.  The 
transfers  of  control  will,  at  the  users  option,  be  either  forward  in  the  program  (but 
never  to  a  narrower  scope  of  access  or  out  of  a  procedure)  or  out  of  the  current 
procedure  through  its  dynamic  (i.e.,  calling  structure.  The  latter  form  requires  an 
exception  handling  formal  parameter  class  (see  C7). 


G8.  There  will  be  source  language  features  which  permit  delay  on  any 
control  path  until  some  specified  time  or  situation  has  occurred,  which  permit 
specification  of  the  relative  priorities  among  parallel  control  paths,  which 
give  access  to  real  time  clocks,  which  permit  asynchronous  hardware 
interrupts  to  be  treated  as  any  other  exception  situation. 

When  parallel  or  pseudo  parallel  paths  appear  in  a  program  it  must  be 
possible  to  specify  their  relative  priorities  and  to  synchronize  their  executions. 
Synchronization  can  be  done  either  through  exclusive  access  to  data  (see  G6)  or 
through  delays  terminated  by  designated  situations  occurring  within  the  program. 
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These  situations  should  include  the  elapse  of  program  specified  time  intervals, 
occurrence  of  hardware  interrupts  and  those  designated  in  the  program.  There  will 
be  no  implicit  evaluation  of  program  determined  situations.  Time  delays  will  be 
program  specifiable  for  both  real  and  simulated  times. 
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H.  SYNTAX  AND  COMMENT  CONVENTIONS 

1.  General  Characteristics 

2.  No  Syntax  Extensions 

3.  Source  Character  Set 

4.  Identifiers  and  Literals 

5.  Lexical  Units  and  Lines 

6.  Keywords 

7.  Comment  Conventions 

8.  Unmatched  Parentheses 

9.  Uniform  Referent  Notation 

10.  Consistency  of  Meaning 


HI.  The  source  language  will  be  free  format  with  an  explicit  statement 
delimiter,  will  allow  the  use  of  mnemonically  significant  identifiers,  will  be 
based  on  conventional  forms,  will  have  a  simple  uniform  and  easily  parsed 
grammar,  will  not  provide  unique  notations  for  special  cases,  will  not  permit 
abbreviation  of  identifiers  or  key  words,  and  will  be  syntactically 
unambiguous. 

Clarity  and  readability  of  programs  will  be  the  primary  criteria  for  selecting  a 
syntax.  Each  of  the  above  points  can  contribute  to  program  clarity.  The  use  of  free 
format,  mnemonic  identifiers  and  conventional  forms  allows  the  programmer  to  use 
notations  which  have  their  familiar  meanings  to  put  down  his  ideas  and  intentions  in 
the  order  and  form  that  humans  think  about  them,  and  to  transfer  skills  he  already 
has  to  the  solution  of  the  problem  at  hand.  A  simple  uniform  language  reduces  the 
number  of  cases  which  must  be  dealt  with  by  anyone  using  the  language.  If 
programs  are  difficult  for  the  translator  to  parse  they  will  be  difficult  for  people. 
Similar  things  should  use  the  same  notations  with  the  special  case  processing 
reserved  for  the  translator  and  object  machine.  The  purpose  of  mnemonic 
identifiers  and  key  words  is  to  be  informative  and  increase  the  distance  between 
lexical  units  of  programs.  This  does  not  prevent  the  use  of  short  identifiers  and 
short  key  words. 


H2.  The  user  will  not  be  able  to  modify  the  source  language  syntax. 
Specifically,  he  will  not  be  able  to  modify  operator  hierarchies,  introduce  new 
precedence  rules,  define  new  key  word  forms  or  define  new  infix  operator 
precedences. 


If  the  user  can  change  the  syntax  of  the  language,  then  he  can  change  the 
basic  character  and  understanding  of  the  language.  The  distinction  between 
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semantic  extensions  and  syntactic  extensions  is  similar  to  that  between  being  able  to 
coin  new  words  in  English  or  being  able  to  move  to  another  natural  language. 
Coining  words  requires  learning  those  new  meanings  before  they  can  be  used,  but  at 
the  same  time  increases  the  power  the  language  for  some  application  areas. 
Changing  the  grammar,  (e  g.,  Franglais,  the  use  of  French  grammar  with  interspersed 
English  words)  however,  undermines  the  basic  understanding  of  the  language  itself, 
changes  the  mode  of  expression,  and  removes  the  commonalities  which  obtain 
between  various  specializations  of  the  language.  Growth  of  a  language  through 
definition  of  new  data  and  operations  and  the  introduction  of  new  words  and  symbols 
to  identify  them  is  desirable,  but  there  should  be  no  provision  for  changing  the 
grammatical  rules  of  the  language.  This  requirement  does  not  conflict  with  E4  and 
does  not  preclude  associating  new  meanings  with  existing  infix  operators. 


H3.  The  syntax  of  source  language  programs  will  be  composable  from  a 
character  set  suitable  for  publication  purposes,  but  no  feature  of  the  language 
will  be  inaccessible  using  the  64  character  ASCII  subset. 

A  common  language  should  use  notations  and  a  character  set  convenient  for 
communicating  algorithms,  programs,  and  programming  techniques  among  its  users. 
On  the  other  hand,  the  language  should  not  require  special  equipment  (e.g.,  card 
readers  and  printers)  for  its  use.  The  use  of  the  64  character  ASCII  subset  will 
make  the  language  compatible  with  the  federal  information  processing  standard  64 
character  set,  FIPS-1,  which  has  been  adopted  by  the  U.S.A.  Standard  code  for 
Information  Interchange  (USASCII).  The  language  definition  will  specify  the 
translation  from  the  publication  language  into  the  restricted  character  set. 


H4.  The  language  definition  will  provide  the  formation  rules  for  identifiers 
and  literals.  These  will  include  literals  for  numbers  and  character  strings  and 
a  break  character  for  use  internal  to  identifiers  and  literals. 

Lexical  units  of  the  language  should  be  defined  in  a  simple  uniform  and  easily 
understood  manner.  Some  possible  break  characters  are  the  space(W.  Dijkstra, 
coding  examples  in  Chapter  I,  "Notes  in  Structured  Programming,"  in  Structured 
Programming  by  O.-J.  Dahl,  E.  W.  Dijkstra  and  C.A.R.  Moore,  Academic  Press, 
1972.  &  Thomas  A.  Standish,  "A  Structured  Program  to  Play  Tic-Tac-Toe,"  notes 
for  Information  and  Computer  Science  3  course  at  Univ.  of  California-Irvine, 
October  1 974)  (i.e.,  any  number  of  spaces  or  end-of-line),  the  underline  and  the  tilde. 
The  space  cannot  be  used  if  identifiers  and  user  defined  infix  operators  are  lexically 
indistinguishable,  but  in  such  a  case  the  formal  grammar  for  the  language  would  be 
ambiguous  (see  HI).  A  literal  break  character  contributes  to  the  readability  of 
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programs  and  makes  the  entry  of  long  literals  less  error  prone.  With  a  space  as  a 
break  character  one  can  enter  multipart  (i.e.,  more  than  one  lexical  unit)  identifiers 
such  as  "REAL  TIME  CLOCK"  or  long  literals,  such  as,  "3. 14159  26535  89793."  Use 
of  a  break  can  also  be  used  to  guarantee  that  missing  quote  brackets  on  character 
literals  do  not  cause  errors  which  propagate  beyond  the  net  end-of-line.  the 
language  should  require  separate  quoting  of  each  line  of  a  long  literal:  "This  is  a  long" 
"literal  string". 


H5.  There  will  be  no  continuation  of  lexical  units  across  lines,  but  there  will 
be  a  way  to  include  object  characters  such  as  end-of-line  in  literal  strings. 

Many  elementary  input  errors  arise  at  the  end  of  lines.  Programs  are  input 
on  line  oriented  media  but  the  concept  of  end-of-line  is  foreign  to  free  format  text. 
Most  of  the  error  prone  aspects  of  end-of-line  can  be  eliminated  by  not  allowing 
lexical  units  to  continue  over  lines.  The  sometimes  undesirable  effects  of  this 
restriction  can  be  avoided  by  permitting  identifiers  and  literals  to  be  composed  from 
more  than  one  lexical  unit  (see  H4)  and  by  evaluating  constant  expressions  at  compile 
time  (see  C4). 


H6.  Key  words  will  be  reserved,  will  be  very  few  in  number,  will  be 

informative,  and  will  not  be  usable  in  contexts  where  an  identifier  can  be  used. 

By  key  words  of  the  language  are  meant  those  symbols  and  strings  which 
have  special  meaning  in  the  syntax  of  programs.  They  introduce  special  syntactic 
forms  such  as  are  used  for  control  structures  and  declarations  or  the  are  used  as  infix 
operators,  or  as  some  form  of  parenthesis.  Key  words  will  be  reserved,  that  is 
unusable  as  identifiers,  to  avoid  confusion  and  ambiguity.  Key  words  will  be  few  in 
number  because  each  new  key  word  introduces  another  case  in  the  parsing  rules  and 
thereby  adds  to  complexity  in  understanding  the  language,  and  because  large 
numbers  of  key  words  inconvenience  and  complicate  the  programmer’s  task  of 
choosing  informative  identifiers.  Key  words  should  be  concise,  but  being 
information  is  more  important  than  being  short.  A  major  exception  is  the  key  word 
introducing  a  comment;  it  is  the  comment  and  not  its  key  word  which  should  do  the 
informing.  Finally,  there  will  be  no  place  in  a  source  language  program  in  which  a 
key  word  can  be  used  in  place  of  an  identifier.  That  is,  functional  form  operations 
and  special  data  items  built  into  the  language  or  accessible  as  a  standard  extension 
will  not  be  treated  as  key  words  but  will  be  treated  as  any  other  identifier. 
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H7.  The  source  language  will  have  a  single  uniform  comment  convention. 
Comments  will  be  easily  distinguishable  from  code,  will  be  introduced  by  a 
single  (or  possibly  two)  language  defined  characters,  will  permit  any 
combination  of  characters  to  appear,  will  be  able  to  appear  anywhere 
reasonable  in  programs,  will  automatically  terminate  at  end-of-line  if  not 
otherwise  terminated,  and  will  not  prohibit  automatic  reformatting  of 
programs. 

These  are  all  obvious  points  which  will  encourage  the  use  of  comments  in 
programs  and  avoid  their  error  prone  features  in  some  existing  languages. 
Comments  anywhere  reasonable  in  a  program  will  not  be  taken  to  mean  that  they  can 
appear  internal  to  a  lexical  unit,  such  as,  an  identifier,  key  word,  or  between  the 
opening  and  closing  brackets  of  a  character  string.  One  comment  convention  which 
nearly  meets  these  criteria  is  to  have  a  special  quote  character  which  begins 
comments  and  with  either  the  quote  or  an  end-of-line  ending  each  comment.  This 
allows  both  embedded  and  line-oriented  comments. 


H8.  The  language  will  not  permit  unmatched  parentheses  of  any  kind. 

Some  programming  languages  permit  closing  parentheses  to  be  omitted.  If, 
for  example,  a  program  contained  more  "BEGINs"  than  "ENDs”  the  translator  might 
insert  enough  "ENDs"  at  the  end  of  the  program  to  make  up  the  difference.  This 
makes  programs  easier  to  write  because  it  sometimes  saves  writing  several  "ENDs" 
at  the  end  of  programs  and  because  it  eliminates  all  syntax  errors  for  missing  "ENDs." 
Failure  to  require  proper  parentheses  matching  makes  it  more  difficult  to  write 
correct  programs.  Good  programming  practice  requires  that  matching  parentheses 
be  included  in  programs  whether  or  not  they  are  required  by  the  language. 
Unfortunately,  if  they  are  not  required  by  the  language  then  there  can  be  no  syntax 
check  to  discover  where  errors  were  made.  The  language  will  require  full 
parentheses  matching.  This  does  not  preclude  syntactic  features  such  as  "case  x  of 
s  1,  s2...sn  end  case"  in  which  "end"  is  paired  with  a  key  word  other  than  "begin."  Nor 
does  it  alone  prohibit  open  forms  such  as  "if-then-else-." 


H9.  There  will  be  a  uniform  referent  notation. 

The  distinction  between  function  calls  and  data  reference  is  one  of 
representation,  not  of  use.  Thus,  there  will  be  no  language  imposed  syntactic 
distinction  between  function  calls  and  data  selection.  If,  for  example,  a  computed 
function  is  replaced  by  a  lookup  table  there  should  be  no  need  to  change  the  calling 
program.  This  does  not  preclude  the  inclusion  of  more  than  one  referent  notation. 


51 


H10.  No  language  defined  symbols  appearing  in  the  same  context  will  have 
essentially  different  meanings. 

This  contributes  to  the  clarity  and  uniformity  of  programs,  protects  against 
psychological  ambiguity  and  avoids  some  error  prone  features  of  extant  languages. 
In  particular,  this  would  exclude  the  use  of  =  to  imply  both  assignment  and  equality, 
would  exclude  conventions  implying  that  parenthesized  parameters  have  special 
semantics  (as  with  PL/1  subroutines),  and  would  exclude  the  use  of  an  assignment 
operator  for  other  than  assignment  (e.g.,  left  hand  side  function  calls).  It  would  not, 
however,  require  different  operator  symbols  for  integer,  real  or  even  matrix 
arithmetic  since  these  are  in  fact  special  cases  of  the  same  abstract  operations  and 
would  allow  the  use  of  generic  functions  applicable  to  several  data  types. 
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I.  DEFAULTS,  CONDITIONAL  COMPILATION  AND  LANGUAGE  RESTRICTIONS 

1.  No  Defaults  in  Program  Logic 

2.  Object  Representation  Specifications  Optional 

3.  Compile  Time  Variables 

4.  Conditional  Compilation 

5.  Simple  Base  Language 

6.  Translator  Restrictions 

7.  Object  Machine  Restrictions 


II.  There  will  be  no  defaults  in  programs  which  affect  the  program  logic. 
That  is,  decisions  which  affect  program  logic  will  be  made  either  irrevocably 
when  the  language  is  defined  or  explicitly  in  each  program. 

The  only  alternative  is  implementation  dependent  defaults  with  the  translator 
determining  the  meaning  of  programs.  What  a  program  does,  should  be 
determinable  from  the  program  and  the  defining  documentation  for  the  programming 
language.  This  does  not  require  that  binding  of  all  program  properties  be  local  to 
each  use.  Quite  the  contrary,  it  would,  for  example,  allow  automatic  definition  of 
assignment  for  all  variables  or  global  specification  of  precision.  What  it  does 
require  is  that  each  decision  be  explicit:  in  the  language  definition,  global  to  some 
scope,  or  local  to  each  use.  Omission  of  any  selection  which  affects  the  program 
logic  will  be  treated  as  an  error  by  the  translator. 


12.  Defaults  will  be  provided  for  special  capabilities  affecting  only  object 
representation  and  other  properties  which  the  programmer  does  not  know  or 
care  about.  Such  defaults  will  always  mean  that  the  programmer  does  not 
care  which  choice  is  made.  The  programmer  will  be  able  to  override  these 
defaults  when  necessary. 

The  language  should  be  oriented  to  provide  a  high  degree  of  management 
control  and  visibility  to  programs  and  toward  self-documenting  programs  with  the 
programmer  required  to  make  his  decisions  explicit.  On  the  other  hand,  the 
programmer  should  not  be  forced  to  overspecify  his  programs  and  thereby  cloud 
their  logic,  unnecessarily  eliminate  opportunities  for  optimization,  and  misrepresent 
arbitrary  choices  as  essential  to  the  program  logic.  Defaults  will  be  allowed,  in  fact, 
encouraged  in  don’t  care  situations.  Such  defaults  will  include  data  representations 
(see  J4),  open  vs.  closed  subroutine  calls  (see  J 5),  and  reentrant  vs.  nonreentrant 
code  generation. 


13.  The  user  will  be  able  to  associate  compile  time  variables  with  programs. 
These  will  include  variables  which  specify  the  object  computer  model  and 
other  aspects  of  the  object  machine  configuration. 

When  a  language  has  different  host  and  object  machines  and  when  its 
compilers  can  produce  code  for  several  configurations  of  a  given  machine,  the 
programmer  should  be  able  to  specify  the  intended  object  machine  configuration. 
The  user  should  have  control  over  the  compile  time  variables  used  in  his  program. 
Typically  they  would  be  associated  with  the  object  computer  model,  the  memory 
size,  special  hardware  options,  the  operating  system  if  present,  peripheral 
equipment  or  other  aspects  of  the  object  machine  configuration.  Compile  time 
variables  will  be  set  outside  the  program,  but  available  for  interrogation  within  the 
program  (see  14  and  C4). 


14.  The  source  language  will  permit  the  use  of  conditional  statements  (e.g., 
case  statements)  dependent  on  the  object  environment  and  other  compile  time 
variables.  In  such  cases  the  conditional  will  be  evaluated  at  compile  time  and 
only  the  selected  path  will  be  compiled. 

An  environmental  inquiry  capability  permits  the  writing  of  common  programs 
and  procedures  which  are  specialized  at  compile  time  by  the  translator  as  a  function 
of  the  intended  object  machine  configuration  or  of  other  compile  time  variables  (see 
13).  This  requirement  is  a  special  case  of  evaluation  of  constant  expressions  at 
compile  time  (see  C4).  It  provides  a  general  purpose  capability  for  conditional 
compilation. 


15.  The  source  language  will  contain  a  simple  clearly  identifiable  base  or 
kernel  which  houses  all  the  power  of  the  language.  To  the  extent  possible, 
the  base  will  be  minimal  with  each  feature  providing  a  single  unique  capablity 
not  otherwise  duplicated  in  the  base.  The  choice  of  the  base  will  not  detract 
from  the  efficiency,  safety,  or  understandability  of  the  language. 

The  capabilities  available  in  any  language  can  be  partitioned  into  two  groups, 
those  which  are  definable  within  the  base  and  those  which  provide  an  essential 
primitive  capability  of  the  language.  The  smaller  and  simpler  the  base  the  easier  the 
language  will  be  to  learn  and  use.  A  clearly  delineated  base  with  features  not  in  the 
base  defined  in  terms  of  the  base,  will  improve  the  ease  and  efficiency  of  learning, 
implementing  and  maintaining  the  language.  Only  the  base  need  be  implemented  to 
make  the  full  source  language  capability  available. 
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Base  features  will  provide  relatively  low  level  general  purpose  capabilities 
not  yet  specialized  for  particular  applications.  There  will  be  no  prohibition  on  a 
translator  incorporating  speciaized  optimizations  for  particular  extensions.  Any 
extension  provided  by  a  translator  will,  however,  be  definable  within  the  base 
language  using  the  built-in  definition  facilities.  Thus,  programs  using  the  extension 
will  be  translatable  by  any  compiler  for  the  language  but  not  necessarily  with  the 
same  object  efficiency. 


16.  Language  restrictions  which  are  dependent  only  on  the  translator  and  not 

on  the  object  machine  will  be  specified  explicitly  in  the  language  definition. 

Limits  on  the  number  of  array  dimensions,  the  length  of  identifiers,  the  number 
of  nested  parentheses  levels  in  expressions,  or  the  number  of  identifiers  in  programs 
are  determined  by  the  translator  and  not  by  the  object  machine.  Ideally,  the  limits 
should  be  set  so  high  that  no  program  (save  the  most  abrasive)  encounters  the  limits. 
In  each  case,  however:  (a)  some  limit  must  be  set,  (b)  whatever  the  limit,  it  will  impose 
on  some  and  therefore  must  be  known  by  the  users  of  the  translator,  (c)  letting  each 
translator  set  its  own  limits  means  that  programs  will  not  be  portable,  (d)  setting  the 
limits  very  high  requires  that  the  translator  be  hosted  only  on  large  machines  and  (e) 
quite  low  limits  do  not  impose  significantly  on  either  the  power  of  the  language  or  the 
readability  of  programs.  Thus,  the  limits  should  be  set  as  part  of  the  language 
definition.  They  should  be  small  enough  that  they  do  not  dominate  the  compiler  and 
large  enough  that  they  do  not  interfere  with  the  usefulness  of  the  language.  If  they 
were  set  at  say  the  99  percent  level  based  on  statistics  from  existing  DoD  computer 
programs  the  limits  might  be  a  few  hundred  for  numbers  of  identifiers  and  less  than 
ten  in  the  other  cases  mentioned  above. 


t "  l  anguage  restrictions  which  are  inherently  dependent  only  on  the  object 
environment  will  not  be  built  into  the  language  definition  or  any  translator. 

Limits  on  the  amount  of  run  time  storage,  access  to  specialized  peripheral 
equipments,  use  of  special  hardware  capabilities  and  access  to  real  time  clocks  are 
dependent  on  the  object  machine  and  configuration.  The  translator  will  report  when 
a  program  exceeds  the  resources  or  capabilities  of  the  intended  object  machine  but 
will  not  build  in  arbitrary  limits  of  its  own. 


55 


J.  EFFICIENT  OBJECT  REPRESENTATIONS  AND  MACHINE  DEPENDENCIES 

1.  Efficient  Object  Code 

2.  Optimizations  Do  Not  Change  Program  Effect 

3.  Machine  Language  Insertions 

4.  Object  Representation  Specifications 

5.  Open  and  Closed  Routine  Calls 


Jl.  The  language  and  its  translators  will  not  impose  run  time  costs  for 
unneeded  or  unused  generality.  They  will  be  capable  of  producing  efficient 
code  for  all  programs. 

The  base  language  and  library  definitions  might  contain  features  and 
capabilities  which  are  not  needed  by  everyone,  or  at  least,  not  be  everyone  all  the 
time.  The  language  should  not  force  programs  to  require  greater  generality  than 
they  need.  When  a  program  does  not  use  a  feature  or  capability  it  should  pay  no  run 
time  cost  for  the  feature  being  in  the  language  or  library.  When  the  full  generality  of 
a  feature  is  not  used,  only  the  necessary  (reduced)  cost  should  be  paid.  Where 
possible,  language  features  (such  as,  automatic  and  dynamic  array  allocation,  process 
scheduling,  file  management  and  I/O  buffering)  which  require  run  time  support 
packages  should  be  provided  as  standard  library  definitions  and  not  as  part  of  the 
base  language  .  The  user  will  not  have  to  pay  time  and  space  for  support  packages 
he  does  not  use.  Neither  will  there  be  automatic  movement  of  programs  or  data 
between  main  store  and  backing  shore  which  is  not  under  program  control  (unless 
the  object  machine  has  virtual  memory  with  underlying  management  beyond  the 
control  of  all  its  users).  Language  features  will  result  in  special  efficient  object 
codes  when  their  full  generality  is  not  used.  A  large  number  of  special  cases  should 
compile  efficiently.  For  example,  a  program  doing  numerical  calculations  on 
unsubscripted  real  variables  should  produce  code  no  worse  than  FORTRAN. 
Parameter  passing  for  single  argument  routines  might  be  implemented  much  less 
expensively  than  multiple  argument  routines. 

One  way  to  reduce  costs  for  unneeded  capabilities  is  to  have  a  base  language 
whose  data  structures  and  operations  provide  a  single  capability  which  is 
composable  and  has  a  straight-forward  implementation  in  the  object  code  of 
conventional  architecture  machines.  If  the  base  language  components  are  easily 
composable  they  can  be  used  to  construct  the  specialized  structures  needed  by 
specific  applications,  if  they  are  simple  and  provide  a  single  capability  they  will  not 
force  the  use  of  unneeded  capabilities  in  order  to  obtain  needed  capabilities,  and  if 
they  are  compatible  with  the  features  normally  found  in  sequential  uniprocessor 
digital  computers  with  random  access  memory  they  will  have  near  minimum  or  at 
least  low  cost  implementation  on  many  object  machines. 
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J2.  Any  optimizations  performed  by  the  translator  will  not  change  the  effect 
of  the  program. 

More  simply,  the  translator  cannot  give  up  program  reliability  and 
correctness,  regardless  of  the  excuse.  Note  that  for  most  programming  languages 
there  are  few  known  safe  optimizations  and  many  unsafe  ones.  The  number  of 
applicable  safe  optimizations  can  be  increased  by  making  more  information  available 
to  the  compiler  and  by  choosing  language  constructs  which  allow  safe  optimizations. 
This  requirement  allows  optimization  by  code  motion  providing  that  motion  does  not 
change  the  effect  of  the  program. 


J3.  The  source  language  will  provide  encapsulated  access  to  machine 
dependent  hardware  facilities  including  machine  language  code  insertions. 

It  is  difficult  to  be  enthusiastic  about  machine  language  insertions.  They 
defeat  the  purpose  of  machine  independence  constrain  the  implementation 
techniques  complicate  the  diagnostics,  impair  the  safety  of  type  checking,  and  detract 
from  the  reliability,  readability,  and  modifiability  of  programs.  The  use  of  machine 
language  insertions  is  particularly  dangerous  in  multiprogramming  applications 
because  they  impair  the  ability  to  exclude,  "a  priori,”  a  large  class  of  time-dependent 
bugs.  Rigid  enforcement  of  scope  rules  by  the  compiler  in  real  time  applications  is  a 
powerful  tool  to  ensure  that  one  sequential  process  will  not  interfere  with  others  in 
an  uncontrolled  fashion.  Similarly,  when  several  independent  programs  are 
executed  in  an  interleaved  fashion,  the  correct  execution  of  each  may  depend  on  the 
others  not  having  improperly  used  machine  language  insertions. 

.  Unfortunately  machine  language  insertions  are  necessary  for  interfacing 

special  purpose  devices,  for  accessing  special  purpose  hardware  capabilities,  and 
for  certain  code  optimizations  on  time  critical  paths.  Here  we  have  an  example  of 

•  Dijkstra’s  dilemma  in  which  the  mismatch  between  high  level  language  programming 

tr  and  the  underlying  hardware  is  unacceptable  and  there  is  no  feasible  way  to  reject 

^  the  hardware.  The  only  remaining  alternative  is  to  "continue  bit  pushing  in  the  old 

-•*  way,  with  all  the  known  ill  effects."  Those  ill  effects  can,  however,  be  constrained  to 

the  smallest  possible  perimeter  in  practice  if  not  in  theory.  The  ability  to  enter 
l  -  machine  language  should  not  be  used  as  an  excuse  to  exclude  otherwise  needed 

;  .  facilities  from  the  HOL;  the  abstract  description  of  programs  in  the  HOL  should  not 

-  require  the  use  of  machine  language  insertions.  The  semantics  of  machine  language 

insertions  will  be  determinable  from  the  HOL  definition  and  the  object  machine 

*  >  description  alone  and  not  dependent  on  the  translator  characteristics  Machine 

language  insertions  will  be  encapsulated  so  they  can  be  easily  recognized  and  so  that 
it  is  clear  which  variables  and  program  identifiers  are  accessed  within  the  insertion. 
The  machine  language  insertions  will  be  permitted  only  within  the  body  of  compile 


time  conditional  statements  (see  14)  which  depend  on  the  object  machine 
configuration  (see  13).  They  will  not  be  allowed  interspersed  with  executable 
statements  of  the  source  language. 


J4.  It  will  be  possible  within  the  source  language  to  specify  the  object 
presentation  of  composite  data  structures.  These  descriptions  will  be 
optional  and  encapsulated  and  will  be  distinct  from  the  logical  description. 
The  user  will  be  able  to  specify  the  time/space  trade-off  to  the  translator.  If 
not  specified,  the  object  representation  will  be  optimal  as  determined  by  the 
translator. 

It  is  often  necessary  to  give  detailed  specifications  of  the  object  data 
representations  to  obtain  maximum  density  for  large  data  files  to  meet  format 
requirements  imposed  by  the  hardware  of  peripheral  equipment,  to  allow  special 
optimizations  on  time  critical  paths,  or  to  ensure  compatibility  when  transferring  data 
between  machines. 

It  will  be  possible  to  specify  the  order  of  the  fields,  the  width  of  fields,  the 
presence  of  don’t  care  fields,  and  the  position  of  word  boundaries.  It  will  be 
possible  to  associate  source  language  identifiers  (data  or  program)  with  special 
machine  addresses.  The  use  of  machine  dependent  characteristics  of  the  object 
representation  will  be  restricted  as  with  machine  dependent  code  (see  J3).  When 
multiple  fields  per  word  are  specified  the  compiler  may  have  to  generate  some  form 
of  shift  and  mask  operations  for  source  program  references  and  assignments  to  those 
variables  (i.e.,  fields).  As  with  machine-language  insertions,  object  data 
specifications  should  be  used  sparingly  and  the  language  features  for  their  use  must 
be  Spartan,  nor  grandiose. 

If  the  object  representation  of  a  composite  data  object  is  not  specified  in  the 
source  program,  there  will  be  no  specific  default  guaranteed  by  the  translator.  The 
translator  might,  for  example,  attempt  to  minimize  access  time  and/or  memory  space 
in  determining  the  objecf  representation.  It  might,  depending  on  the  object  machine 
characteristics,  assign  variables  and  fields  of  records  to  full  words,  but  assign  array 
elements  to  the  smallest  of  bits,  bytes,  half  words,  words  or  exact  multiple  words 
permitted  by  the  logical  description. 


J5.  The  programmer  will  be  able  to  specify  whether  calls  on  a  routine  are  to 
have  an  open  or  closed  implementation.  An  open  and  a  closed  routine  of  the 
same  description  will  have  identical  semantics. 
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The  use  of  inline  open  procedures  can  reduce  the  run  time  execution  costs 
significantly  in  some  cases.  There  are  the  obvious  advantages  in  eliminating  the 
parameter  passing,  in  avoiding  the  saving  of  return  marks,  and  in  not  having  to  pass 
arguments  to  and  from  the  routine.  A  less  obvious,  but  often  more  important 
advantage  in  saving  run  time  costs  is  the  ability  to  execute  constant  portions  of 
routines  at  compile  time  and,  thereby,  eliminate  time  and  space  for  those  portions  of 
the  procedure  body  at  run  time.  Open  routine  capability  is  especially  important  for 
machine  language  insertions. 

The  distinction  between  open  and  closed  implementation  of  a  routine  is  an 
efficiency  consideration  and  should  not  affect  the  function  of  the  routine.  Thus,  an 
open  routine  will  differ  from  a  syntax  macro  in  that  (a)  its  global  environment  is  that  of 
its  definition  and  not  that  of  its  call  and  (b)  multiple  occurrences  of  a  formal  value  (i.e., 
read  only)  parameter  in  the  body  have  the  same  value.  If  a  routine  is  not  specified 
as  either  open  or  closed  the  choice  will  be  optimal  as  determined  by  the  translator. 


K.  PROGRAM  ENVIRONMENT 

1.  Operating  System  Not  Required 

2.  Program  Assembly 

3.  Software  Development  Tools 

4.  Translator  Options 

5.  Assertions  and  Other  Optional  Specifications 


Kl.  The  language  will  not  require  that  the  object  machine  have  an  operating 
system.  When  the  object  machine  does  have  an  operating  system  or 
executive  program,  the  hardware/operating  system  combination  will  be 
interpreted  as  defining  an  abstract  machine  which  acts  as  the  object  machine 
for  the  translator. 

A  language  definition  cannot  dictate  the  architecture  of  existing  object 
machines  whether  defined  entirely  in  hardware  or  in  a  hardware/software 
combination.  It  can  provide  a  source  language  representation  of  all  the  needed 
capabilities  and  attempt  to  choose  these  so  they  have  an  obvious  and  efficient 
translation  in  the  object  machines. 


K2.  The  language  will  support  the  integration  of  separately  written  modules 

into  an  operational  program. 

Separately  written  modules  in  the  form  of  routines  and  type  definitions  are 
necessary  for  the  management  of  large  software  efforts  and  for  effective  use  of 
libraries.  The  user  will  be  able  to  cause  anything  in  any  accessible  library  to  be 
inserted  into  his  program.  This  is  a  requirement  for  separate  definition  but  not 
necessarily  for  separate  compilation.  The  decision  as  to  whether  separately 
defined  program  modules  are  to  be  maintained  in  source  or  object  language  form  is  a 
question  of  implementation  efficiency,  will  be  a  local  management  option  and  will  not 
be  imposed  by  the  language  definition.  The  trade-offs  involved  are  complicated  by 
other  requirements  for  type  checking  of  parameters  (see  C6),  for  open  subroutines 
(see  J5),  for  efficient  object  representations  (see  J 1),  and  for  constant  expression 
evaluation  at  compile  time  (see  C4).  In  general,  separate  compilation  increases  the 
difficulty  and  expense  of  the  interface  validations  needed  for  program  safety  and 
reliability  and  detracts  from  object  program  efficiency  by  removing  many  of  the 
optimizations  otherwise  possible  at  the  interfaces,  but  at  the  same  time  it  reduces  the 
cost  and  complexity  of  compilation. 
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K3.  A  family  of  programming  tools  and  aids  in  the  form  of  support  packages 
including  linkers,  loaders  and  debugging  systems  will  be  made  available  with 
the  language  and  its  translators.  There  will  be  a  consistent  easily  used  user 
interface  for  these  tools. 

The  time  has  passed  in  which  a  programming  language  can  be  considered  in 
isolation  from  its  programming  environment.  The  availability  of  programming  tools 
which  need  not  be  developed  and/or  supported  by  individual  projects  is  a  major 
factor  in  the  acceptability  of  a  language.  There  is  no  need  to  restrict  the  kinds  or 
form  of  support  software  available  in  the  programming  environment,  and  continued 
development  of  new  tools  should  be  encouraged  and  made  available  in  a  competitive 
market.  It  is,  however,  desirable  that  tools  be  developed  in  their  own  source 
language  to  simplify  their  portability  and  maintainability. 


K4.  A  variety  of  useful  options  to  aid  generation,  test,  documentation  and 
modification  of  programs  will  be  provided  as  support  software  available  with 
the  language  or  as  translator  options.  As  a  minimum  these  will  include 
program  editing,  post-  mortem  analysis  and  diagnostics,  program  reformating 
for  standard  indentations,  and  cross-reference  generation. 

There  will  be  special  facilities  to  aid  the  generation,  test,  documentation  and 
modification  of  programs.  The  "best"  set  of  capabilities  and  their  proper  form  is  not 
currently  known.  Since  nonstandard  translator  options  and  availability  of 
nonstandard  software  tools  and  aids  do  not  adversely  affect  software  commonality, 
the  language  definition  and  standards  will  not  dictate  arbitrary  choices.  Instead,  the 
development  of  language  associated  tools  and  aids  will  be  encouraged  within  the 
constraint  of  implementing  and  supporting  the  source  language  as  defined.  Tools  and 
debugging  aids  will  be  source  language  oriented. 

Some  of  the  translator  options  which  have  been  suggested  and  may  be  useful 
include  the  following.  Code  might  be  compiled  for  assertions  which  would  give  run 
time  warnings  when  the  value  of  the  assertion  predicate  is  false.  It  might  provide 
run  time  tracing  of  specified  program  variables.  Dimensional  analysis  might  be  done 
on  units  of  measure  specifications.  Special  optimizations  might  be  invoked.  There 
might  be  capability  for  timing  analysis  and  gathering  run  time  statistics.  There  might 
be  translator  supplied  feedback  to  provide  management  visibility  regarding  progress 
and  conformity  with  local  conventions.  The  user  might  be  able  to  inhibit  code 
generation.  There  might  be  facilities  for  compiling  program  patches  and  for 
controlling  access  to  language  features.  The  translator  might  provide  a  listing  of  the 
number  of  instructions  generated  against  corresponding  source  inputs  and/or  an 
estimate  of  their  execution  times.  It  might  provide  a  variety  of  listing  options. 
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K5.  The  source  language  will  permit  inclusion  of  assertions,  assumptions, 
axiomatic  definitions  of  data  types,  debugging  specifications;,  and  units  of 
measures  in  programs.  Because  many  assertional  methods  are  not  yet 
powerful  enough  for  practical  use,  nor  sufficiently  well  developed  for 
standardization,  they  will  have  the  status  of  comments. 

There  are  many  opinions  on  the  desirability,  usefulness,  and  proper  form  for 
each  of  these  specifications.  Better  program  documentation  is  needed  and 
specifications  of  these  kinds  may  help.  Specifications  also  introduce  the  possibility 
of  automated  testing,  run  time  verification  of  predicates,  formal  program  proofs,  and 
dimensional  analysis.  The  language  will  not  prohibit  inclusion  of  these  forms  of 
specification  if  and  when  they  become  available  for  practical  use  in  programs. 
Assertions,  assumptions,  axiomatic  definitions  and  units  of  measure  in  source 
language  programs  should  be  enclosed  in  special  brackets  and  should  be  treated  as 
interpreted  comments  --  comments  which  are  delimited  by  special  comment  brackets 
and  which  may  be  interpreted  during  translation  or  debugging  to  provide  units 
analysis,  verification  of  assertions  and  assumptions,  etc— but  whose  interpretation 
would  be  optional  to  translator  implementations. 


62 


L.  TRANSLATORS 

1.  No  Superset  Implementations 

2.  No  Subset  Implementations 

3.  Low-Cost  Translation 

4.  Many  Object  Machines 

5.  Self-Hosting  Not  Required 

6.  Translator  Checking  Required 

7.  Diagnostic  Messages 

8.  Translator  Internal  Structure 

9.  Self-Implementable  Language 


LI.  No  implementation  of  the  language  will  contain  source  language  features 
which  are  not  defined  in  the  language  standard.  Any  interpretation  of  a 
language  feature  not  explicitly  permitted  by  the  language  definition  will  be 
forbidden. 

This  guarantees  that  use  of  programs  and  software  subsystems  will  not  be 
restricted  to  a  particular  site  by  virtue  of  using  their  unique  version  of  the  language. 
It  also  represents  a  commitment  to  freezing  the  source  language,  inhibiting 
innovations  and  growth  in  the  form  of  the  source  language,  and  confining  the  base 
language  to  the  current  state  of  the  art  in  return  for  stability,  wider  applicability  of 
software  tools,  reusable  software,  greater  software  visibility,  and  increased  payoff 
for  tool  building  efforts.  It  does  not,  however,  disallow  library  definition 
optimizations  which  are  translator  unique. 


L2.  Every  translator  for  the  language  will  implement  the  entire  base 
language.  There  will  be  no  subset  implementations  of  the  base  language. 

If  individual  compilers  implement  only  a  subset  of  the  language,  the  there  is  no 
chance  for  software  commonality.  If  a  translator  does  not  implement  the  entire 
language,  it  cannot  give  its  users  access  to  standard  supported  libraries  or  to 
application  programs  implemented  on  some  other  translator.  Requiring  that  the  full 
language  be  implemented  will  be  expensive  only  if  the  base  language  is  large, 
complex,  and  nonuniform.  The  intended  source  language  product  from  this  effort  is  a 
small  simple  uniform  base  language  with  the  specialized  features,  support  packages, 
and  complex  features  relegated  to  library  routines  not  requiring  direct  translator 
support.  If  simple  low  cost  translators  are  not  feasible  for  the  selected  language, 
then  the  language  is  too  large  and  complex  to  be  standardized  and  the  goal  of 
language  commonality  will  not  be  achievable. 


L3.  The  translator  will  minimize  compile  time  costs.  A  goal  of  any  translator 
for  the  language  will  be  low  cost  translation. 

Where  practical  and  beneficial  the  user  will  have  control  over  the  level  of 
optimization  applied  to  his  programs.  The  programmer  will  have  control  over  the 
tradeoffs  between  compile  time  and  run  time  costs.  The  desire  for  small  efficient 
translators  which  can  be  hosted  by  machines  with  limited  size  and  capability  should 
influence  the  design  of  the  base  language  against  inclusion  of  unnecessary  features 
and  towards  systematic  treatment  of  features  which  are  included.  The  goal  will  be 
effective  use  of  the  available  machines  both  in  object  execution  and  translation  and 
not  maximal  speed  of  translation. 

Translation  costs  depend  not  only  on  the  compiler  but  the  language  design. 
Both  the  translator  and  the  language  design  will  emphasize  low  cost  translation,  but 
in  an  environment  of  large  and  long-lived  software  products  this  will  be  secondary  to 
requirements  for  reliability  and  maintainability.  Language  features  will  be  chosen  to 
ensure  that  they  do  not  impose  costs  for  unneeded  generality  and  that  needed 
capabilities  can  be  translated  into  efficient  object  representations.  This  means  that 
the  inherent  costs  of  specific  language  features  is  the  context  of  the  total  language 
must  be  understood  by  the  designers,  implementers  and  users  of  the  language.  One 
consequence  should  be  that  trivial  programs  compile  and  run  in  trivial  time.  On  the 
other  hand,  significant  optimization  is  not  expected  from  a  minimal  cost  translator. 


L4.  Translators  will  be  able  to  produce  code  for  a  variety  of  object 
machines.  The  machine  independent  parts  of  translators  might  be  built 
independent  of  the  code  generators. 

There  is  currently  no  common  widely  used  computer  in  the  DoD.  There  are 
at  least  250  different  models  of  commercial  machines  in  use  in  DoD  with  many  more 
specialized  machines.  A  common  language  must  be  applicable  to  a  wide  variety  of 
models  and  sizes  of  machines.  Translators  might  be  written  so  they  can  produce 
object  code  for  several  machines.  This  reduces  the  proliferation  of  translators  and 
makes  the  full  power  of  an  existing  translator  available  at  the  cost  of  producing  an 
additional  code  generator. 


L5.  The  translator  need  not  be  able  to  run  on  all  the  object  machines. 
Self-hosting  is  not  required,  but  is  often  desirable. 

The  DoD  operational  programming  environment  includes  many  small  machines 
which  are  unable  to  support  adequately  the  design,  documentation,  test,  and 
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debugging  aids  necessary  for  the  development  of  timely,  reliable  or  efficient 
software.  Large  machine  users  should  not  be  penalized  for  the  restrictions  of  small 
machines  when  a  common  language  is  used.  On  the  other  hand,  the  size  of  machines 
which  can  host  translators  should  be  kept  as  small  as  possible  by  avoiding 
unnecessary  generality  in  the  language. 


L6.  The  translator  will  do  full  syntax  checking,  will  check  all  operations  and 
parameters  for  type  compatibility  and  will  verify  that  all  language  imposed 
semantic  restrictions  on  the  source  programs  are  met.  It  will  not 
automatically  correct  errors  detected  at  compile  time. 

The  purpose  of  source  language  redundancy  and  avoidance  of  error  prone 
language  features  is  reliability.  The  price  is  paid  in  programmer  inconvenience  in 
having  to  specify  his  intent  in  greater  detail.  The  payoff  comes  when  the  translator 
checks  that  the  source  program  is  internally  consistent  and  adheres  to  its  authors’ 
stated  intentions.  There  is  a  clear  trade-off  between  error  avoidance  and 
programming  ease;  surveys  conducted  in  the  Services  show  that  the  programmers  as 
well  as  managers  will  opt  for  error  avoidance  over  ease  when  given  the  choice.  The 
same  choice  is  dictated  by  the  need  for  well  documented  maintainable  software. 


L7.  The  translator  will  produce  compile  time  explanatory  diagnostic  error 
and  warning  messages.  A  suggested  set  of  error  and  warning  situations  will 
be  provided  as  part  of  the  language  definition. 

The  translator  will  attempt  to  provide  the  maximal  useful  feedback  to  its  user. 
Diagnostic  messages  will  not  be  coded  but  will  be  explanatory  and  in  source  language 
terms.  Translators  will  continue  processing  and  checking  after  errors  have  been 
found  but  should  be  careful  not  to  generate  erroneous  messages  because  of 
translator  confusion.  The  translator  will  always  produce  correct  code;  when  source 
programs  errors  are  encountered  by  the  translator  or  referenced  program  structures 
omitted,  the  compiler  will  produce  code  to  cause  a  run  time  exception  condition  upon 
any  attempt  to  execute  those  parts  of  the  program.  Warnings  will  be  generated 
when  a  source  language  construct  is  exceptionally  expensive  to  implement  on  the 
specified  object  machine.  A  suggested  set  of  diagnostic  messages  provided  as  part 
of  the  language  definition  contributes  to  commonality  in  the  implementation  and  use  of 
the  language.  The  discipline  of  designing  diagnostic  messages  keyed  to  the  design 
may  also  uncover  pitfalls  in  the  language  design  and  thereby  contribute  to  a  more 
precise  and  better  understood  language  description. 
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L8.  The  characteristics  of  translator  implementations  will  not  be  dictated  by 
the  language  definition  or  standards. 

The  adoption  of  a  common  language  is  a  commitment  to  the  current  state  of  the 
art  for  programming  language  design  for  some  duration.  It  does  not,  however, 
prevent  access  to  new  software  and  hardware  technology,  new  techniques  and  new 
management  strategies  which  do  not  impact  the  source  language  definition.  In 
particular,  innovation  should  be  encouraged  in  the  development  of  translators  for  a 
common  language  providing  they  implement  exactly  the  source  language  as  defined. 
Translators  like  all  computer  programs  should  be  written  in  expectation  of  change. 


L9.  Translators  for  the  language  will  be  written  in  their  own  source 
language. 

There  will  be  at  least  one  implementation  of  the  translator  in  its  own  language 
which  does  all  parsing  and  compile-time  checking  and  produces  an  output  suitable 
for  easy  translation  to  specific  object  machines.  If  the  language  is  well-defined  and 
uniform  in  structure,  a  self-description  will  contribute  to  understanding  of  the 
language.  The  availability  of  the  machine  independent  portion  of  a  translator  will 
make  the  full  power  of  the  language  available  to  any  object  machine  at  the  cost  of 
producing  an  additional  code  generator  (whose  cost  may  be  high)  and  it  reduces  the 
likelihood  of  incompatible  implementations.  Translators  written  in  their  own  source 
language  are  automatically  available  on  any  of  their  object  machines  providing  the 
object  machine  has  sufficient  resources  to  support  a  compiler. 
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M.  LANGUAGE  DEFINITION,  STANDARDS  AND  CONTROL 

1.  Existing  Language  Features  Only 

2.  Unambiguous  Definition 

3.  Language  Documentation  Required 

4.  Control  Agent  Required 

5.  Support  Agent  Required 

6.  Library  Standards  and  Support  Required 


Ml.  The  language  will  be  composed  from  features  which  are  within  the  state 
of  the  art  and  any  design  or  redesign  which  is  necessary  to  achieve  the 
needed  characteristics  will  be  conducted  as  an  engineering  design  effort  and 
not  as  a  research  project. 

The  adoption  of  a  common  language  can  be  successful  only  if  it  makes 
available  a  modern  programming  language  compatible  with  the  latest  software 
technology  and  is  compatible  with  "best"  current  programming  practice  but  the 
design  and  implementation  of  the  language  should  not  require  additional  research  or 
require  use  of  untried  ideas.  State-of-the-art  cannot,  however,  be  taken  to  mean 
that  a  feature  has  been  incorporated  in  an  operational  DoD  language  and  used  for  an 
extended  period,  or  DoD  will  be  forever  tied  to  the  technology  of  FORTRAN-like 
languages;  but  there  must  be  some  assurances  through  analysis  and  use  that  its 
benefits  and  deficiencies  are  known.  The  larger  and  more  complex  the  structure, 
the  more  analysis  and  use  that  should  be  required.  Language  design  should  parallel 
other  engineering  design  efforts  in  that  it  is  a  task  of  consolidation  and  not  innovation. 
The  language  designer  should  be  familiar  with  the  many  choices  in  semantic  and 
syntactic  features  of  language  and  should  strive  to  compose  the  best  of  these  into  a 
consistent  structure  congruous  with  the  needed  characteristics.  The  language 
should  be  composed  from  known  semantic  features  and  familiar  notations,  but  the  use 
of  proven  feature  should  not  necessarily  impose  that  notation.  The  language  must 
not  just  be  a  combination  of  existing  features  which  satisfy  the  individual 
requirements  but  must  be  held  together  by  a  consistent  and  uniform  structure  which 
acts  to  minimize  the  number  of  concepts,  consolidates  divergent  features  and 
simplifies  the  whole. 


M2.  The  semantics  of  the  language  will  be  defined  unambiguously  and 
clearly.  To  the  extent  a  formal  definition  assists  in  attaining  these  objectives, 
the  language’s  semantics  will  be  specified  formally. 


A  complete  and  unambiguous  definition  of  a  common  language  is  essential. 
Otherwise  each  translator  will  resolve  the  ambiguities  and  fill  in  the  gaps  in  its  own 
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unique  way.  There  are  currently  a  variety  of  methods  for  formal  specification  of 
programming  language  semantics  but  it  remains  a  major  effort  to  produce  a  rigorous 
formal  description  and  the  resulting  products  are  of  questionable  practical  value. 
The  real  value  in  attempting  a  formal  definition  is  that  it  reveals  incomplete  and 
ambiguous  specifications.  An  attempt  will  be  made  to  provide  a  formal  definition  of 
any  language  selected  but  success  in  that  effort  should  not  be  requisite  to  its 
selection.  Formal  specification  of  the  language  might  take  the  form  of  an  axiomatic 
definition,  use  of  the  Vienna  Definition  Language,  or  use  of  some  other  formal 
semantic  system. 


M3.  The  user  documentation  of  the  language  will  be  complete  and  will 
include  both  a  tutorial  introductory  description  and  a  format  in-depth 
description.  The  language  will  be  defined  as  if  it  were  the  machine  level 
language  of  an  abstract  digital  computer. 

The  language  should  be  intuitively  correct  and  easily  learned  and  understood 
by  its  potential  users.  The  language  definition  might  include  an  Algol-60  like 
description^.  Naur  (Ed  ),  "Revised  Report  on  the  Algorithmic  Language  Algol-60," 
Communication  of  the  A.C.M.  Vol.6,  No.  1,  January  1963,  p.  1-17.)  with  the 
source  language  syntax  given  in  BNF  or  some  other  easily  understood  metalanguage 
and  the  corresponding  semantics  given  in  English.  As  with  the  descriptions  of  digital 
computer  hardware,  the  semantics  and  syntax  of  each  feature  must  be  defined 
precisely  and  unambiguously.  The  action  of  any  legal  program  will  be  determinable 
from  the  program  and  the  language  description  alone.  Any  computation  which  can 
be  described  in  the  language  will  ultimately  draw  only  on  capabilities  which  are  built 
into  the  language.  No  characteristics  of  the  source  language  will  be  dependent  on 
the  idiosyncrasies  of  its  translators. 

The  language  documentation  will  include  syntax,  semantics  and  examples  of 
each  language  construct,  listings  of  all  key  words  and  language  defined  defaults. 
Examples  shall  be  included  to  show  the  intended  use  of  language  features  and  to 
illustrate  proper  use  of  the  language.  Particularly  expensive  and  inexpensive 
constructs  will  be  pointed  out.  Each  document  will  identify  its  purpose  and 
prerequisites  for  its  use 


MA.  The  language  will  be  configuration  managed  throughout  its  total  life 
cycle  and  will  be  controlled  at  the  DoD  level  to  ensure  that  there  is  only  one 
version  of  the  source  language  and  that  all  translators  conform  to  that 
standard. 


Without  controls  a  hopefully  common  language  may  become  another  umbrella 
under  which  new  languages  proliferate  while  retaining  the  same  name.  All 
compilers  will  be  tested  and  certified  for  conformity  to  the  standard  specification  and 
freedom  from  known  errors  prior  to  their  release  for  use  in  production  projects. 
The  language  manager  will  be  on  the  OSD  staff,  but  a  group  within  the  Military 
Departments  or  Agencies  might  act  as  the  executive  agent.  A  configuration  control 
board  will  be  instituted  with  user  representation  and  chaired  by  a  member  of  the  OSD 
staff. 


M5.  There  will  be  identified  support  agent(s)  responsible  for  maintaining  the 
translators  and  for  associated  design,  development,  debugging  and 
maintenance  aids. 

Language  commonality  is  an  essential  step  in  achieving  software  commonality, 
but  the  real  benefits  accrue  when  projects  and  contractors  can  draw  on  existing 
software  with  assurance  that  it  will  be  supported,  when  systems  can  build  from  off 
the  shelf  components  or  at  least  with  common  tools,  and  when  efforts  can  be  spent  to 
expand  existing  capabilities  rather  than  building  from  scratch.  Support  of  common 
widely  used  tools  and  aids  should  be  provided  independent  of  projects  if  common 
software  is  to  be  widely  used.  Support  should  be  on  a  DoD-wide  basis  with  final 
responsibility  resting  with  a  stable  group  or  groups  of  qualified  in-house  personnel. 


M6.  There  will  be  standards  and  support  agents  for  common  libraries 
including  application-oriented  libraries. 

In  a  given  application  of  a  programming  language  three  levels  of  the  system 
must  be  learned  and  used:  the  base  language,  the  standard  library  definitions  used  in 
that  application  area,  and  the  local  application  programs.  Users  are  responsible  for 
the  local  application  programs  and  local  definitions  but  not  for  the  language  and  its 
libraries  which  are  used  by  many  projects  and  sites.  A  principal  user  might  act  as 
agent  for  an  entire  application  area. 


